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

Thanks

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.

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.

I updated the gist for the newest Mesa release:
https://gist.github.com/devernay/71f3d7661d910e6494a9

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.

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.

A script that builds a mangled osmesa up to the osmesa demo program is at:
https://github.com/devernay/osmesa-install

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
gles=
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"
    fi
done
(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.

> echo "* fixing gl_mangle.h...

look for the script in the githup directly, don't copy-paste the above text, which is broken.

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 ?

Thanks!

> - 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.

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)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/992.