Bug 91724 - GL/gl_mangle.h misses symbols from GLES/gl.h
Summary: GL/gl_mangle.h misses symbols from GLES/gl.h
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 10.6
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
Depends on:
Blocks: 94994
  Show dependency treegraph
Reported: 2015-08-22 09:37 UTC by Frederic Devernay
Modified: 2017-06-26 10:11 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

patch file for glmangle.h (172.38 KB, patch)
2017-06-26 10:11 UTC, Frederic Devernay
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Devernay 2015-08-22 09:37:44 UTC
When using a statically linked libMangledOSMesa32.a, One gets these undefined symbols at link time:

Undefined symbols for architecture x86_64:
  "_glAlphaFuncx", referenced from:
      _static_functions in libMangledOSMesa32.a(glapi_libglapi_la-glapi_getproc.o)
  "_glClearColorx", referenced from:
      _static_functions in libMangledOSMesa32.a(glapi_libglapi_la-glapi_getproc.o)
[long list of _gl.*x undefined symbols]

obviously, functions defined in GLES/gl.h should be mangled too.

To fix it, include ../GLES/gl.h when regenerating gl_mangle.h:

(cd include/GL; sed -e 's@gl.h glext.h@gl.h glext.h ../GLES/gl.h@' -e 's@\^GLAPI@^GL_?API@' -i .orig gl_mangle.h)
(cd include/GL; sh ./gl_mangle.h > gl_mangle.h.new && mv gl_mangle.h.new gl_mangle.h)

now glAlphaFuncx and friends are correctly mangled
Comment 1 Emil Velikov 2015-08-24 15:28:02 UTC
Hi Frederic,

I could be missing something but I thought that mangling was only for GLX and desktop GL ? Thus I'm not sure that including GLES/* is the correct thing to do.

As mangled gl never really worked here, due to unrelated build issues, can you retry after updating the header. There are instructions some in gl_mangle.h

Comment 2 Frederic Devernay 2015-08-24 16:24:17 UTC
Hi Emil,

I first tried updating the header, but the gl*x functions were still not mangled.

I have build instructions for OSX on https://gist.github.com/devernay/71f3d7661d910e6494a9

It builds mangled Mesa and mangled GLU, and I'll add the lines to compile the demos too, so that you can check that linking really fails with those undefined symbols.

It probably works on Linux without the OSX patches.

I'm building without GLES, but the gl*x functions are still present, and required for linking.
Comment 3 Frederic Devernay 2015-08-24 16:51:44 UTC
just added the lines to build the demo. If you don't apply my patch to gl_mangle.h, you end up with undefined symbols.
Comment 4 Frederic Devernay 2015-12-15 08:42:46 UTC
I updated the gist for the newest Mesa release:

Note that, despite what Emil said in http://lists.freedesktop.org/archives/mesa-dev/2014-December/072575.html using dlopen(RTLD_LOCAL) may not be a viable option, for example if both the system's libGL and the Mesa libGL depend on libraries with the same soname (llvm or X11 for example) but which are incompatible for some reason (in my case, I am loading Mesa from a plugin, and I don't know what the host application has loaded before - the only safe way is to use a mangled Mesa).

In short, RTLD_LOCAL works for the loaded library (in my case, it is the plugin), but not its dependencies.
See https://sourceware.org/ml/libc-help/2014-08/msg00042.html for a full explanation.

So please, don't remove the option to mangle Mesa symbols, unless there is a viable and portable possibility to load a non-mangled mesa together with the system libGL.
Comment 5 Emil Velikov 2016-11-24 13:49:45 UTC
Hi Frederic, sorry for dropping the ball on this one.

Can you please attach (as plain text) the instructions and demo program that you've mentioned - the gist seems to have been removed.

If you already have a patch please send it to the mailing list.
Comment 6 Frederic Devernay 2016-11-25 12:01:49 UTC
A script that builds a mangled osmesa up to the osmesa demo program is at:

If you just want the swrast driver, set  osmesadriver=1 on line 19.

Here is the part that fixes gl_mangle.h.

echo "* fixing gl_mangle.h..."
# edit include/GL/gl_mangle.h, add ../GLES*/gl[0-9]*.h to the "files" variable and change GLAPI in the grep line to GL_API
for h in GLES/gl.h GLES2/gl2.h GLES3/gl3.h GLES3/gl31.h GLES3/gl32.h; do
    if [ -f include/$h ]; then
	gles="$gles ../$h"
(cd include/GL; sed -e 's@gl.h glext.h@gl.h glext.h '"$gles"'@' -e 's@\^GLAPI@^GL_\\?API@' -i.orig gl_mangle.h)
(cd include/GL; sh ./gl_mangle.h > gl_mangle.h.new && mv gl_mangle.h.new gl_mangle.h)

Just comment it if you want to test without it.

If you don't want to apply any of the provided patches (which fix actual issues with the current version), just remove the patch directory.

Note that in the latest Mesa (13.0.1), GLES3/gl32.h has to be included too, or there are two more undefined symbols (glBlendBarrier and glPrimitiveBoundingBox). These should be mangled too. For safety, I just mangle the entry points from all GL and GLES versions.
Comment 7 Frederic Devernay 2016-11-25 12:04:20 UTC
> echo "* fixing gl_mangle.h...

look for the script in the githup directly, don't copy-paste the above text, which is broken.
Comment 8 Emil Velikov 2016-11-27 00:48:22 UTC
Why no attach files here, sob :-(

Also please send patches to the ML for review.

A few things from a quick look (I might be off here):
- Using/setting GL_GLEXT_PROTOTYPES is a _very_ bad idea.
Both eglGetProcAddress and glXGetProcAddress can (and they will) return !NULL for "glHamSandwich". I'd imagine th OSMesa one will do the same.

- Do you set USE_MGL_NAMESPACE when building the demo app ? 
Without it the (header) symbols are not mangled, thus you end up linking/using the normal glFoo ones.

- Is this issue specific to static linking and/or !Linux systems ? I've tried building osmesa the other day it seemed fine.

- Do you see this problem isolated to the gallium and/or classic osmesa ?

Comment 9 Frederic Devernay 2017-06-26 10:06:24 UTC
> - Using/setting GL_GLEXT_PROTOTYPES is a _very_ bad idea.

Agreed. This patch *fixes* glext.h, but I do not use it anywhere. It is fixed just in case someone crazy enough wants to use it.

More importantly, it fixes gl_mangle.h, which is included by glapi_getproc.c when compiling a *mangled* OSMesa.

> - Do you set USE_MGL_NAMESPACE when building the demo app ? 

better than that, I add "-include $osmesaprefix/include/GL/gl_mangle.h -include $osmesaprefix/include/GL/glu_mangle.h" to the CFLAGS, so that I am certain only the mangled versions will be used.

See the last 10 lines of my build script at https://github.com/devernay/osmesa-install/blob/master/osmesa-install.sh#L653

> - Is this issue specific to static linking and/or !Linux systems ? I've tried building osmesa the other day it seemed fine.

Did you try building a *mangled* osmesa? This issue only happens when building a *mangled* OSMesa on Linux, MacOS, and Windows. 

Of could, you should be careful to not link with the system's opengl, or you wont't have any undefined symbol.

Non-mangled osmesa works fine, but the HUGE advantage of mangles OSMesa is that you can easily use both OpenGL and OSMesa in the same app.

> - Do you see this problem isolated to the gallium and/or classic osmesa ?

This affects all drivers using glapi, see the initial error message.
Comment 10 Frederic Devernay 2017-06-26 10:11:50 UTC
Created attachment 132249 [details] [review]
patch file for glmangle.h

Here's the patch for mesa 17.1.3.
Note that in the #define section, some functions are reordered after running the script, but more importantly the missing functions are now defined.

There were no less than 127 missing defines in gl_mangle.h.
The first one is glAlphaFuncx, which appears as the first error when compiling a static mangles osmesa (see the initial error message in the first comment)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.