Dear Maintainer,

New versions of libgles1-mesa seems to export less functions. Eg.
glGenFramebuffersOES

Here a comparaison between wheezy and sid.

Under wheezy:

~~~
$ cat testgloes.c
#include <stdlib.h>
#include <GLES/gl.h>
#define GL_GLEXT_PROTOTYPES
#include <GLES/glext.h>
int main(void) {
        glGenFramebuffersOES(0, NULL);
        return 0;
}
$ gcc testgloes.c -W -Wall `pkg-config glesv1_cm --cflags --libs`
$ # FINE
$ apt-cache policy libgles1-mesa
libgles1-mesa:
  Installé : 8.0.5-4+deb7u2
  Candidat : 8.0.5-4+deb7u2
 Table de version :
 *** 8.0.5-4+deb7u2 0
        990 http://debian.savoirfairelinux.net/debian/ wheezy/main amd64
Packages
        990 http://security.debian.org/ wheezy/updates/main amd64 Packages
        100 /var/lib/dpkg/status
$ readelf -Ws /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 | grep
glGenFramebuffersOES
   107: 0000000000005160     0 FUNC    GLOBAL DEFAULT   12 glGenFramebuffersOES
~~~

Under sid:

~~~
$ gcc testgloes.c -W -Wall `pkg-config glesv1_cm --cflags --libs`
/tmp/ccc4pDT1.o: In function `main':
testgloes.c:(.text+0xf): undefined reference to `glGenFramebuffersOES'
collect2: error: ld returned 1 exit status
$ # NOT FINE :(
$ apt-cache policy libgles1-mesa
libgles1-mesa:
  Installé : 10.2.3-1
  Candidat : 10.2.3-1
 Table de version :
 *** 10.2.3-1 0
        500 http://http.debian.net/debian/ sid/main amd64 Packages
        100 /var/lib/dpkg/status
$ readelf -Ws /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 | grep
glGenFramebuffersOES
$ # NOTHING :(
~~~

Salut Jean,

Jean Privat <jean.privat@gmail.com> (2014-07-10):

a quick grep suggests you want libepoxy:
  $ nm -D /usr/lib/x86_64-linux-gnu/libepoxy.so.0.0.0|grep glGenFramebuffersOES
  00000000002e3478 D epoxy_glGenFramebuffersOES

since libepoxy-dev has:
  /usr/include/epoxy/gl_generated.h:#define glGenFramebuffersOES epoxy_glGenFramebuffersOES

Its summary line reads “Epoxy is a library for handling OpenGL function
pointer management for you”.

Mraw,
KiBi.

Presumably from:
http://cgit.freedesktop.org/mesa/mesa/?id=1a59f9a131318e1239b47b9ea4fe7c84f461cf37

I don't believe this is a bug, you need to call getprocaddress to get at
these entry points.

Cheers,
Julien

Make that
http://cgit.freedesktop.org/mesa/mesa/commit?id=1a59f9a131318e1239b47b9ea4fe7c84f461cf37

Cheers,
Julien

Thank you to get what seems the origin of my issue.

I still see two problems (but I am not an expert, so they could be not
real problems, or have well known workarounds).

First, I see a regression, since a library with a given soname in sid
offers less functions than the same library with the same soname in
wheezy

Second, I see a .h/.so mismatch since the `/usr/include/GLES/glext.h`
file from libgles1-mesa-dev=10.2.3-1 proposes some functions not
available in the `/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1` file in
libgles1-mesa=10.2.3-1

Therefore I assume this could bite other people, that is the reason a
write a bug report.

More personally (and maybe to give more context), I found the problem
when compiling code written by other people (that compiled on some
previous sid versions). So, while I successfully used libepoxy (thanks
to Cyril) or updating code to use gl instead of gles, I still prefer
not to diverge from my uptream without a good reason.