[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

GitLab Migration User  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #11 from GitLab Migration User  ---
-- 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #10 from Frederic Devernay  ---
Created attachment 132249
  --> https://bugs.freedesktop.org/attachment.cgi?id=132249=edit
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)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #9 from Frederic Devernay  ---
> - 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #8 from Emil Velikov  ---
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!

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #7 from Frederic Devernay  ---
> echo "* fixing gl_mangle.h...

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #6 from Frederic Devernay  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #5 from Emil Velikov  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

Frederic Devernay  changed:

   What|Removed |Added

 Blocks||94994

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #4 from Frederic Devernay  ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #1 from Emil Velikov emil.l.veli...@gmail.com ---
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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #2 from Frederic Devernay frederic.dever...@m4x.org ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

--- Comment #3 from Frederic Devernay frederic.dever...@m4x.org ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

Frederic Devernay frederic.dever...@m4x.org changed:

   What|Removed |Added

 CC||frederic.dever...@m4x.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 91724] GL/gl_mangle.h misses symbols from GLES/gl.h

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91724

Bug ID: 91724
   Summary: GL/gl_mangle.h misses symbols from GLES/gl.h
   Product: Mesa
   Version: 10.6
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: frederic.dever...@m4x.org
QA Contact: mesa-dev@lists.freedesktop.org

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev