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