[Mesa-dev] Compiling llvm windows name mangled

[Brian Paul]

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