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: 2016-11-27 00:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


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 ?


bug/show.html.tmpl processed on Jan 16, 2017 at 17:22:17.
(provided by the Example extension).