Re: [Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
Quoting Jon Turney (2018-01-28 06:24:11)
> ---
> 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')
We don't use parens around conditionals except to group them logically, can we
drop the extra parens here?
>dep_clock = []
> else
>dep_clock = cc.find_library('rt')
> --
> 2.15.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
Hi Jon,
On 28 January 2018 at 14:24, Jon Turney 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
Quoting Emil Velikov (2018-01-30 10:56:42)
> Hi Jon,
>
> On 28 January 2018 at 14:24, Jon Turney 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.
I'm pretty sure that the autotools build sets --no-undefined too, right?
Dylan
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
On 30 January 2018 at 20:27, Dylan Baker wrote:
> Quoting Emil Velikov (2018-01-30 10:56:42)
>> Hi Jon,
>>
>> On 28 January 2018 at 14:24, Jon Turney 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
Re: [Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
On 31/01/2018 15:21, Emil Velikov wrote:
On 30 January 2018 at 20:27, Dylan Baker wrote:
Quoting Emil Velikov (2018-01-30 10:56:42)
Hi Jon,
On 28 January 2018 at 14:24, Jon Turney 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)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] meson: osx doesn't have librt, so don't require it
On 31 January 2018 at 16:07, Jon Turney wrote:
> On 31/01/2018 15:21, Emil Velikov wrote:
>>
>> On 30 January 2018 at 20:27, Dylan Baker wrote:
>>>
>>> Quoting Emil Velikov (2018-01-30 10:56:42)
Hi Jon,
On 28 January 2018 at 14:24, Jon Turney
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)
Right, so in this case:
- targeting pre 10.12 where API is missing (be that librt or elsewhere)
- 990bd49f and this patch are off, remove the linkage and rely on the
linker GC magic
I think, one wants to distinct between presence vs linkage requirements.
ATM they're assumed to be the same thing.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
