On 12/11/2014 09:20 AM, Jose Fonseca wrote:
On 11/12/14 08:40, Emil Velikov wrote:
Hi Jose,
On 10/12/14 14:18, Jose Fonseca wrote:
I never tried, but it doesn't surprise that ?USE_MGL_NAMESPACE
doesn't work properly on Windows.
At very least the src/mesa/drivers/windows/gdi and
src/gallium/targets/libgl-gdi targets will fail because the .DEF
files there explicitly request the non-mangled symbols.
Not sure if src/mesa/drivers/osmesa will produce something useful.
You can ask scons to only build osmesa by passing "scons osmesa .."
?
That said, there's little to zero merit in USE_MGL_NAMESPACE on
Windows because on Windows it's fine to have different DLLs exporting
the same symbols, since unlike Unixes, DLLs exports are not dumped
into a global namespace.
As you mentioned MGL and *nix in one sentience - did you have any
success building a mangled libgl (under Linux) recently ?
No, never tried.
I've had a few unsuccessful attempts 2+months ago, and it is still
somewhat busted.
If it's unmistakably busted we should consider just removing it.
Even on Unices it's possible to dlopen() shared objects without poluting
global namespace via RTLD_LOCAL flag, so application shoule be able to
use osmesa and the system's libGL.so simultanouesly without fearing
symbol clash. That is, I'm not aware of any merit in keeping such a
heavy handed hammer in our code base like mangled symbols...
Every once in a while someone complains that include/GL/gl_mange.h is
out of date so I guess a few people use it.
But I'd be happy to see it go if nobody _really_ needs it.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
