> 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.
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. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camqw0om9maapqyaouzshgmwfe+-qbgm6e307fibp5kbfm8g...@mail.gmail.com
