[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