NDKr7 can't see glDrawTexiOES

[devi prasad]

Hi, I noticed that with NDK r7 I can no longer compile code containing
::glDrawTexiOES. The same compiles with NDK r6b. Why so?

dp

[David Turner]

On Thu, Dec 29, 2011 at 9:57 AM, devi prasad <dpra...@gmail.com> wrote:

Hi, I noticed that with NDK r7 I can no longer compile code containing
::glDrawTexiOES. The same compiles with NDK r6b. Why so?

This is weird.

NDK r7 comes with updated versions of the GLES headers from Khronos. I guess there is something in the new headers. Can you file a bug at b.android.com about this. I'll take a look.

- David

dp

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[devi prasad]

Hi, David - it dawned upon me now that ::glDrawTexiOES is not
available for GLES2 apps. The GLES/glext.h contains the prototype,
while GLES2/gl2ext.h doesn't, as expected. I realized that I was using
different versions of the code to compare the behaviors of NDK r6b and
NDK r7.

I'm sorry about the confusion.

Thanks!
devi prasad
bad

[devi prasad]

Well, it turned out that I posted my "findings" too soon. I ran into
the same problem again with NDKr7. I added the following line to my
Android.mk, and the compilation problems disappeared:

LOCAL_CFLAGS += -D GL_GLEXT_PROTOTYPES

A diff between the GLES/glext.h in the android-9 platform headers
distributed with r6b and r7 shows the guard across *OES prototypes.

Is this going to stick post-NDKr7? Are there any recommendations?

David - Sorry about the earlier post. FYI, I haven't filed a bug yet;
not sure if this is actually a bug :)

thanks
dp

[David Turner]

It looks like defining GL_GLEXT_PROTOTYPES to get prototype function definitions is expected from the glext.h header users. See Issue 5.3 at  http://www.opengl.org/registry/ABI/ 

However, I think this is not a good idea. Relying on a fixed extension function symbol being exported by the system's EGL/GLES shared libraries is not a good idea, i.e. in general there is no guarantee that it will be exported by the system version of these libraries (which are simple wrappers around hardware-specific GLES libraries). You should really try to lookup the function address with eglProcAddress() instead.

[devi prasad]

Alright, makes sense. Thanks, David.

[Futumsh]

On Jan 2, 8:59 am, David Turner <di...@android.com> wrote:
> It looks like defining GL_GLEXT_PROTOTYPES to get prototype function

> definitions is expected from the glext.h header users. See Issue 5.3 athttp://www.opengl.org/registry/ABI/

>
> However, I think this is not a good idea. Relying on a fixed extension
> function symbol being exported by the system's EGL/GLES shared libraries is
> not a good idea, i.e. in general there is no guarantee that it will be
> exported by the system version of these libraries (which are simple
> wrappers around hardware-specific GLES libraries). You should really try to
> lookup the function address with eglProcAddress() instead.

Since it appears eglGetProcAddress did not appear until android-9, is
it safe/allowed for use when supporting older versions? What is the
correct mechanism to use when supporting Eclair and later?