[Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
emil.l.velikov at gmail.com
Wed Jan 31 15:21:09 UTC 2018
On 30 January 2018 at 20:27, Dylan Baker <dylan at pnwbakers.com> wrote:
> Quoting Emil Velikov (2018-01-30 10:56:42)
>> Hi Jon,
>> On 28 January 2018 at 14:24, Jon Turney <jon.turney at dronecode.org.uk> wrote:
>> > ---
>> > meson.build | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > diff --git a/meson.build b/meson.build
>> > index 7e194a9f10d..8fdbaa8b8d8 100644
>> > --- a/meson.build
>> > +++ b/meson.build
>> > @@ -935,7 +935,7 @@ elif with_dri_i965 and get_option('shader-cache')
>> > endif
>> > # Determine whether or not the rt library is needed for time functions
>> > -if cc.has_function('clock_gettime')
>> > +if cc.has_function('clock_gettime') or (host_machine.system() == 'darwin')
>> Absolutely no objections against the patch - just a small question.
>> If the meson/autotools check fails, does this mean that the resulting
>> binaries are having unresolved reference wrt said symbol?
> Not for meson, it builds -Wl,--no-undefined (or it's MSVC equivalent) by
> default, so it shouldn't be possible to get unresolved symbols in a binary or
> shared library.
Right, the question is why does the test (has_function) fails?
A few possible solutions come to mind, but only one with toolchain
handy can confirm.
- the test is broken (regardless meson/autotools/foo implementation)
- the symbol is indirectly resolved
The est does not pull libfoo, while the final binary does. Libfoo
pulls libbar with the latter providing the symbol.
- the final binary is having unresolved reference
- all the clock_gettime references get 'magically' removed due to the
linker garbage collector
>From a quick search OSX 10.12 (or so) has clock_gettime. But details
are extremely sparse :-(
More information about the mesa-dev