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

[Jon Turney]

On 31/01/2018 15:21, Emil Velikov wrote:
> 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?

Some misunderstanding going on here, I think. It fails if the function 
isn't present.

(We then go on to report the failure as being librt not found, not that 
we couldn't work out how to find clock_gettime, but perhaps that's a 
separate issue)

> 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 :-(

This change (and the check that autoconf is currently doing) is not needed.

If we're targeting OSX 10.12 or later, clock_gettime() exists.

Commit 990bd49f might have made sense once, but I think now that 
clock_gettime is used in include/c11/threads_posix.h, we're going to 
fail to build for OSX prior to 10.12, even when not trying to link with 
librt.

(I also had a patch to provide an implementation of clock_gettime if the 
target is an earlier OSX version, but I dropped it as probably not very 
useful)