[Buildroot] [PATCH 2/2] nilfs-utils: drop NPTL dependency
Peter Korsgaard
peter at korsgaard.com
Thu Sep 27 12:11:26 UTC 2018
>>>>> "Kurt" == Kurt Van Dijck <dev.kurt at vandijck-laurijssen.be> writes:
> On wo, 26 sep 2018 20:20:45 +0200, Fabrice Fontaine wrote:
>> The latest uClibc-ng version (1.0.30) provides clock_nanosleep() even
>> for non NPTL configurations.
> Do you mean that buildroot must only be built with uClibc-ng > 1.0.30?
I guess you mean >= . Indeed, only uClibc-ng 1.0.30 built with our
defconfig is really supported.
1.0.30 was released back in April, so requiring this for our November
release is IMHO OK.
>>
>> Signed-off-by: Fabrice Fontaine <fontaine.fabrice at gmail.com>
>> ---
>> package/nilfs-utils/Config.in | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/package/nilfs-utils/Config.in b/package/nilfs-utils/Config.in
>> index e245dc4656..7b239b1af5 100644
>> --- a/package/nilfs-utils/Config.in
>> +++ b/package/nilfs-utils/Config.in
>> @@ -2,7 +2,6 @@ config BR2_PACKAGE_NILFS_UTILS
>> bool "nilfs-utils"
>> depends on BR2_USE_MMU # util-linux libmount, libblkid
>> depends on BR2_TOOLCHAIN_HAS_THREADS # sem_open()
>> - depends on BR2_TOOLCHAIN_HAS_THREADS_NPTL # clock_nanosleep()
> I think you break other configurations here.
> Did you try testbuilds with this change?
It does not introduce breakage as such. Before, if you had an uClibc-ng
config without NPTL you couldn't enable this package - Now you can. If
you are using an old pre-1.0.30 external uClibc-ng toolchain then it
will not actually build, but that is a general problem with external
uClibc-ng toolchains if they are not in sync with the internal
toolchain.
In any case, the solution is simply - Just rebuild your toolchain.
> I remember a strong debate some time ago where the final outcome was
> that this constructs is put on several places, and that it would be
> better to introduce something like BR2_TOOLCHAIN_HAS_CLOCK_NANOSLEEP
> or something alike instead. This would really solve the issue.
The problem is that a user of an external uClibc-ng toolchain has to
answer all these fine grained configuration options (and we have to
verify them), so it doesn't really scale.
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list