[Mesa-dev] [PATCH 7/7] meson: fix deps and underlinkage of libGL

Jon Turney jon.turney at dronecode.org.uk
Thu Nov 30 15:13:24 UTC 2017


On 29/11/2017 17:34, Dylan Baker wrote:
> Quoting Jon Turney (2017-11-29 08:22:54)
>> On 28/11/2017 18:21, Dylan Baker wrote:
>>> Quoting Emil Velikov (2017-11-27 06:31:35)
>>>> IIRC Windows mandates binaries with unresolved symbols.
>>>> Other platforms allow such behaviour.
>>>>
>>>> I think we want to set b_lundef=true, to catch these issues as part of
>>>> the build process.
>>>> We already do so in the autotools, android and at least partially in scons.
>>>>
>>>> One would need a workaround for the sanitizers [1] analogous to our
>>>> autotools and scons builds.
>>>>
[...]
>>>
>>> JFYI,
>>>
>>> b_lundef is true by default, and we don't override it. In this case (unless I'm
>>> completely misreading/remembering [I wrote a very similar patch in my macos
>>> branch]), the linkage is correct for Linux (possibly BSD too), but incorrect for
>>> macOS, Cygwin, and Windows.
>>
>> If this is the case, think this suggests that there's something
>> systematically wrong here, and this isn't the right fix...
>>
>> I'll look into this a bit more.
> 
> I'm not sure there is anything wrong. with_dri_platfrom == 'drm' will always be
> true on Linux/BSD, so really on Linux this patch has no functional changes, but
> it will have functional changes in cases where with_dri_platform != 'drm', or am
> I missing something?

Maybe it's me that's missing something...

There are references to functions provided by these libraries (xcb_glx, 
xcb, x11_xcb) in common code.

The linux build includes these libraries on the link line, and 
DT_NEEEDED tags are emitted for them (i.e. it is not underlinked, which 
is what I was assuming...)

All other things being equal, there shouldn't be the need to take 
special steps to link with those libraries when with_dri_platfrom != 'drm'

[time passes... Thorin sits down and starts singing about gold]

So it seems, when building for linux, xcb_glx and x11_xcb arrive in the 
link line from libloader_dri3_helper via libloader.

... and indeed when built -Ddri3=false, libGL has unresolved symbols for 
these libraries.


More information about the mesa-dev mailing list