[Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it

[Emil Velikov]

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?
>>
>> Thanks
>> Emil
>
> 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 :-(

-Emil