On 30 January 2018 at 20:27, Dylan Baker <dy...@pnwbakers.com> wrote:
> Quoting Emil Velikov (2018-01-30 10:56:42)
>> Hi Jon,
>>
>> On 28 January 2018 at 14:24, Jon Turney <jon.tur...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
