| Message ID | 1425735600-16762-2-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Superseded |
| Headers | show |
Thomas, All, On 2015-03-07 14:39 +0100, Thomas Petazzoni spake thusly: > uClibc-ng does not support linuxthreads or linuxthreads.old on > architectures that have NPTL support. This creates another complicated > dependency: dependeing on the uClibc version being used, not the same > thread implementations are available. > > In order to handle this situation, this patch introduces three hidden > booleans: > > - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > - BR2_UCLIBC_VERSION_SUPPORTS_NPTL > > They are selected by the different uClibc versions, depending on which > thread implementation they support on the different architectures. > > Then, the choice of the thread implementation can rely on those > booleans to know if a given thread implementation is available in the > current architecture / uClibc version selection. > > This makes sure that unusable thread implementation do not get > selected, therefore fixing build issues such as: > > http://autobuild.buildroot.org/results/89e/89e423bee040cbce3e82cd89f1191efaac490c0d/ > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> However, a small comment, see below... > --- > package/uclibc/Config.in | 43 +++++++++++++++++++++++++++++++++---------- > 1 file changed, 33 insertions(+), 10 deletions(-) > > diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in > index 3a65752..c66373d 100644 > --- a/package/uclibc/Config.in > +++ b/package/uclibc/Config.in > @@ -7,6 +7,15 @@ config BR2_PACKAGE_UCLIBC > > comment "uClibc Options" > > +config BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > + bool > + > +config BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > + bool > + > +config BR2_UCLIBC_VERSION_SUPPORTS_NPTL > + bool > + > choice > prompt "uClibc C library Version" > default BR2_UCLIBC_VERSION_0_9_33 > @@ -15,21 +24,39 @@ choice > > config BR2_UCLIBC_VERSION_0_9_33 > bool "uClibc 0.9.33.x" > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > + if !BR2_bfin > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > + if !BR2_bfin && !BR2_x86_i386 > depends on !(BR2_arc || BR2_xtensa) > > config BR2_UCLIBC_VERSION_ARC_GIT > bool "uClibc Git ARC" > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > depends on BR2_arc > > config BR2_UCLIBC_NG_VERSION_1_0_0 > bool "uClibc-ng 1.0.0" > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > + if BR2_arc || BR2_m68k > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > + if BR2_arc || BR2_bfin || BR2_m68k > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > + if !BR2_arc && !BR2_bfin && !BR2_x86_i386 I will trust you on these combinations. ;-) > config BR2_UCLIBC_VERSION_XTENSA_GIT > bool "uClibc Git Xtensa" > depends on BR2_xtensa > + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS_OLD Please be consistent: either put the 'select' before or after the 'depends' as you prefer, but do it consistently across all options. ;-) I tend to prefer depends before select, as it seems more logical to me, but I don't mind either, as long as it is consistent. Regards, Yann E. MORIN.
Dear Yann E. MORIN, On Sat, 7 Mar 2015 15:34:11 +0100, Yann E. MORIN wrote: > > config BR2_UCLIBC_NG_VERSION_1_0_0 > > bool "uClibc-ng 1.0.0" > > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > > + if BR2_arc || BR2_m68k > > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > > + if BR2_arc || BR2_bfin || BR2_m68k > > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > > + if !BR2_arc && !BR2_bfin && !BR2_x86_i386 > > I will trust you on these combinations. ;-) Well, I was actually looking for some review on those combinations. In short: * There should not be any change for uClibc itself (0.9.33, special ARC and Xtensa version, snapshot) * For uClibc-ng, the change should be that NPTL becomes the only available option, unless you're on ARC, Blackfin or i386 (and by i386, I really mean only i386: NPTL on >= i486 is fine). > Please be consistent: either put the 'select' before or after the > 'depends' as you prefer, but do it consistently across all options. ;-) > > I tend to prefer depends before select, as it seems more logical to me, > but I don't mind either, as long as it is consistent. Sure, I'll fix that up. But I'd prefer to have a review on the combinations. Thanks, Thomas
Hi Thomas, Thomas Petazzoni wrote, > uClibc-ng does not support linuxthreads or linuxthreads.old on > architectures that have NPTL support. This creates another complicated > dependency: dependeing on the uClibc version being used, not the same > thread implementations are available. > > In order to handle this situation, this patch introduces three hidden > booleans: > > - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > - BR2_UCLIBC_VERSION_SUPPORTS_NPTL > > They are selected by the different uClibc versions, depending on which > thread implementation they support on the different architectures. > > Then, the choice of the thread implementation can rely on those > booleans to know if a given thread implementation is available in the > current architecture / uClibc version selection. Looks good to me so far. I am still unsatisfied about the ARC situation. If you use this branch of gcc: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/tree/arc-4.8-tls You get a working toolchain with TLS support and can use uClibc-git or uClibc-ng 1.0.0 with NPTL. best regards Waldemar
Thomas, All, On 2015-03-07 14:39 +0100, Thomas Petazzoni spake thusly: > uClibc-ng does not support linuxthreads or linuxthreads.old on > architectures that have NPTL support. This creates another complicated > dependency: dependeing on the uClibc version being used, not the same > thread implementations are available. > > In order to handle this situation, this patch introduces three hidden > booleans: > > - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > - BR2_UCLIBC_VERSION_SUPPORTS_NPTL > > They are selected by the different uClibc versions, depending on which > thread implementation they support on the different architectures. > > Then, the choice of the thread implementation can rely on those > booleans to know if a given thread implementation is available in the > current architecture / uClibc version selection. > > This makes sure that unusable thread implementation do not get > selected, therefore fixing build issues such as: > > http://autobuild.buildroot.org/results/89e/89e423bee040cbce3e82cd89f1191efaac490c0d/ > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Here's a further review, since you asked for it... ;-) > config BR2_UCLIBC_VERSION_0_9_33 > bool "uClibc 0.9.33.x" > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > + if !BR2_bfin > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > + if !BR2_bfin && !BR2_x86_i386 > depends on !(BR2_arc || BR2_xtensa) > > config BR2_UCLIBC_VERSION_ARC_GIT > bool "uClibc Git ARC" > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > depends on BR2_arc > > config BR2_UCLIBC_NG_VERSION_1_0_0 > bool "uClibc-ng 1.0.0" > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > + if BR2_arc || BR2_m68k > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > + if BR2_arc || BR2_bfin || BR2_m68k > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > + if !BR2_arc && !BR2_bfin && !BR2_x86_i386 From what I can see, uclibc-ng on branch 1.0 : LT.old LT NPTL Notes arc - - Y arm Y - Y bfin Y Y - i386 - - - i?86 - - Y except i386 m68k Y Y - microblaze Y Y - not used in BR mips - - Y nios2 Y Y - not used in BR powerpc - - Y sh - - Y sparc - - Y x86_64 - - Y xtensa - - Y So, I guess your selection is incorrect, and you should have: select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ if BR2_bfin || BR2_m68k select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ if BR2_bfin || BR2_m68k || BR2_arm || BR2_armeb select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ if !BR2_bfin && !BR2_m68k && !BR2_x86_i386 Regards, Yann E. MORIN. > config BR2_UCLIBC_VERSION_XTENSA_GIT > bool "uClibc Git Xtensa" > depends on BR2_xtensa > + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS_OLD > > config BR2_UCLIBC_VERSION_SNAPSHOT > bool "daily snapshot" > + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS if !BR2_bfin && !BR2_xtensa > + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS_OLD > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > + if !BR2_bfin && !BR2_x86_i386 && !BR2_xtensa > depends on !(BR2_arc) > > endchoice > @@ -101,8 +128,9 @@ config BR2_TOOLCHAIN_BUILDROOT_LOCALE > > choice > prompt "Thread library implementation" > - default BR2_PTHREADS_NATIVE if !BR2_xtensa > - default BR2_PTHREADS_OLD > + default BR2_PTHREADS_NATIVE if BR2_UCLIBC_VERSION_SUPPORTS_NPTL > + default BR2_PTHREADS_OLD if BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > + default BR2_PTHREADS if BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > help > Use this option to select the thread library implementation > that should be used in your toolchain. Not all thread > @@ -115,24 +143,19 @@ choice > > config BR2_PTHREADS > bool "linuxthreads" > - depends on !BR2_bfin > - depends on !BR2_xtensa > select BR2_TOOLCHAIN_HAS_THREADS > + depends on BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS > > config BR2_PTHREADS_OLD > bool "linuxthreads (stable/old)" > select BR2_TOOLCHAIN_HAS_THREADS > + depends on BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD > > config BR2_PTHREADS_NATIVE > bool "Native POSIX Threading (NPTL)" > select BR2_TOOLCHAIN_HAS_THREADS > select BR2_TOOLCHAIN_HAS_THREADS_NPTL > - depends on !BR2_arc > - depends on !BR2_bfin > - # There is NPTL support for Xtensa in uClibc-ng, but > - # not in the main uClibc repository. > - depends on !BR2_xtensa || !BR2_UCLIBC_VERSION_XTENSA_GIT > - depends on !BR2_x86_i386 > + depends on BR2_UCLIBC_VERSION_SUPPORTS_NPTL > endchoice > > config BR2_PTHREAD_DEBUG > -- > 2.1.0 > > _______________________________________________ > buildroot mailing list > buildroot@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
Dear Yann E. MORIN, On Sat, 7 Mar 2015 18:39:28 +0100, Yann E. MORIN wrote: > > config BR2_UCLIBC_NG_VERSION_1_0_0 > > bool "uClibc-ng 1.0.0" > > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > > + if BR2_arc || BR2_m68k > > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > > + if BR2_arc || BR2_bfin || BR2_m68k > > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > > + if !BR2_arc && !BR2_bfin && !BR2_x86_i386 > > From what I can see, uclibc-ng on branch 1.0 : > > LT.old LT NPTL Notes > arc - - Y Ah, right, I missed that. So it means that right now we can't build an ARC toolchain with uClibc-ng in Buildroot: the ARC compiler version we use does not have TLS support, which is required for NPTL. So ARC + uClibc-ng is not possible right now. > arm Y - Y Yes, but Waldemar's wish is basically to not use LT or LT.old when there is NPTL support available. Which I believe makes sense. See his patch at http://patchwork.ozlabs.org/patch/446288/ where he was making LT and LT.old not available on ARM and ARMeb. > bfin Y Y - Correct. That needs to be fixed in my patch. > i386 - - - > i?86 - - Y except i386 > m68k Y Y - > microblaze Y Y - not used in BR > mips - - Y > nios2 Y Y - not used in BR > powerpc - - Y > sh - - Y > sparc - - Y > x86_64 - - Y > xtensa - - Y > > > So, I guess your selection is incorrect, and you should have: > > select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > if BR2_bfin || BR2_m68k > select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > if BR2_bfin || BR2_m68k || BR2_arm || BR2_armeb > select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > if !BR2_bfin && !BR2_m68k && !BR2_x86_i386 Ok, except the ARM case where I disagree (see above), and handling the ARC situation, I'm OK with your proposal. Thanks, Thomas
Waldemar, Alexey, On Sat, 7 Mar 2015 18:20:39 +0100, Waldemar Brodkorb wrote: > I am still unsatisfied about the ARC situation. > If you use this branch of gcc: > https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/tree/arc-4.8-tls > > You get a working toolchain with TLS support and can use uClibc-git > or uClibc-ng 1.0.0 with NPTL. I'm adding Alexey from Synopsys in Cc. Alexey, when do you think we can switch to a gcc version that has TLS support in Buildroot, for the ARC architecture ? This would allow us to enable NPTL on ARC, using uClibc-ng. Thanks, Thomas
Thomas, All, On 2015-03-08 08:40 +0100, Thomas Petazzoni spake thusly: > On Sat, 7 Mar 2015 18:39:28 +0100, Yann E. MORIN wrote: > > > config BR2_UCLIBC_NG_VERSION_1_0_0 > > > bool "uClibc-ng 1.0.0" > > > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > > > + if BR2_arc || BR2_m68k > > > + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > > > + if BR2_arc || BR2_bfin || BR2_m68k > > > + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > > > + if !BR2_arc && !BR2_bfin && !BR2_x86_i386 > > > > From what I can see, uclibc-ng on branch 1.0 : > > > > LT.old LT NPTL Notes > > arc - - Y > > Ah, right, I missed that. So it means that right now we can't build an > ARC toolchain with uClibc-ng in Buildroot: the ARC compiler version we > use does not have TLS support, which is required for NPTL. So ARC + > uClibc-ng is not possible right now. > > > arm Y - Y > > Yes, but Waldemar's wish is basically to not use LT or LT.old when > there is NPTL support available. Which I believe makes sense. See his > patch at http://patchwork.ozlabs.org/patch/446288/ where he was making > LT and LT.old not available on ARM and ARMeb. Eh, I never said we _had_ to have LT/LT.old when NPTL is available. ;-) > > bfin Y Y - > > Correct. That needs to be fixed in my patch. > > > i386 - - - > > i?86 - - Y except i386 > > m68k Y Y - > > microblaze Y Y - not used in BR > > mips - - Y > > nios2 Y Y - not used in BR > > powerpc - - Y > > sh - - Y > > sparc - - Y > > x86_64 - - Y > > xtensa - - Y > > > > > > So, I guess your selection is incorrect, and you should have: > > > > select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ > > if BR2_bfin || BR2_m68k > > select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ > > if BR2_bfin || BR2_m68k || BR2_arm || BR2_armeb > > select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ > > if !BR2_bfin && !BR2_m68k && !BR2_x86_i386 > > Ok, except the ARM case where I disagree (see above), and handling the > ARC situation, I'm OK with your proposal. OK. One more thing: since uClibc-ng supports microblaze and nios2, we could enable uClibc (as in "uClibc in Buildroot") to build Buildroot toolchains for those two archs, no? Regards, Yann E. MORIN.
Hi, Yann E. MORIN wrote, > > OK. One more thing: since uClibc-ng supports microblaze and nios2, we > could enable uClibc (as in "uClibc in Buildroot") to build Buildroot > toolchains for those two archs, no? No. Unfortunately this is another can of worms in the uClibc world :( Microblaze GNU libc and musl support is fine. uClibc does not support NPTL/TLS for this architecture. As one of the Microblaze maintainers told me, the no-MMU microblaze stuff is seldom used nowadays. Gcc needs patching to find shared library loader with uClibc. So there is a lot of stuff todo, before Microblaze and uClibc can be used. At least there is good support for Qemu, so you can directly start to hack without buying expensive FPGA hardware :) NIOS2 GNU libc support was added recently and you can compile a toolchain with upstream gcc and binutils. NIOS2 in uClibc is really bad maintained. There is no TLS/NPTL support and you are getting some compile errors when trying to build with LT.old or no threads. I haven't found any usable external GIT repository with newer support. So if anyone know a working version of uClibc/uClinux for NIOS2 I am happy to merge the needed changes. There is a patch set for Qemu here: https://lists.gnu.org/archive/html/qemu-devel/2012-09/msg01229.html But it is not in latest Qemu-Git. I did not removed both architectures as I am planning to get them in a better shape. best regards Waldemar
Hi Thomas, On Sun, 2015-03-08 at 08:41 +0100, Thomas Petazzoni wrote: > Waldemar, Alexey, > > On Sat, 7 Mar 2015 18:20:39 +0100, Waldemar Brodkorb wrote: > > > I am still unsatisfied about the ARC situation. > > If you use this branch of gcc: > > https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/tree/arc-4.8-tls > > > > You get a working toolchain with TLS support and can use uClibc-git > > or uClibc-ng 1.0.0 with NPTL. > > I'm adding Alexey from Synopsys in Cc. Alexey, when do you think we can > switch to a gcc version that has TLS support in Buildroot, for the ARC > architecture ? > > This would allow us to enable NPTL on ARC, using uClibc-ng. We're actively working on enabling TLS/NPTL support for ARC and our current plan is to get it done by the next release of ARC tools - sometime later this spring. Even though most of things in TLS/NPTL tools for ARC work pretty well there're still issues to be resolved. And because this all is still in works we don't yet have particular branches in binutils and gcc repos I may recommend you to try. As for uClibc we tend to apply all changes to "arc-mainline-dev" branch in "https://github.com/foss-for-synopsys-dwc-arc-processors/uClibc" repo. Still I'd propose to wait a bit until we get something that could be labeled as RC and then if you're willing to start running build or run-time tests I'll let you know. Anyway once we enable TLS/NPTL in GNU tools for ARC I'll send patch that enables TLS for ARC in Buildroot - we're looking forward to having TLS as a default option for ARC (as most of other arches do) because of known benefits of TLS threading compared to Linuxthreads. So stay tuned. -Alexey
Dear Alexey Brodkin, On Mon, 9 Mar 2015 08:27:09 +0000, Alexey Brodkin wrote: > We're actively working on enabling TLS/NPTL support for ARC and our > current plan is to get it done by the next release of ARC tools - > sometime later this spring. > > Even though most of things in TLS/NPTL tools for ARC work pretty well > there're still issues to be resolved. And because this all is still in > works we don't yet have particular branches in binutils and gcc repos I > may recommend you to try. > > As for uClibc we tend to apply all changes to "arc-mainline-dev" branch > in "https://github.com/foss-for-synopsys-dwc-arc-processors/uClibc" > repo. > > Still I'd propose to wait a bit until we get something that could be > labeled as RC and then if you're willing to start running build or > run-time tests I'll let you know. > > Anyway once we enable TLS/NPTL in GNU tools for ARC I'll send patch that > enables TLS for ARC in Buildroot - we're looking forward to having TLS > as a default option for ARC (as most of other arches do) because of > known benefits of TLS threading compared to Linuxthreads. > > So stay tuned. Thanks Alexey for this summary of TLS support in ARC, very useful. As you suggest, we'll wait for the next release of the ARC tools to enable TLS by default on ARC. Thanks! Thomas
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in index 3a65752..c66373d 100644 --- a/package/uclibc/Config.in +++ b/package/uclibc/Config.in @@ -7,6 +7,15 @@ config BR2_PACKAGE_UCLIBC comment "uClibc Options" +config BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS + bool + +config BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD + bool + +config BR2_UCLIBC_VERSION_SUPPORTS_NPTL + bool + choice prompt "uClibc C library Version" default BR2_UCLIBC_VERSION_0_9_33 @@ -15,21 +24,39 @@ choice config BR2_UCLIBC_VERSION_0_9_33 bool "uClibc 0.9.33.x" + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ + if !BR2_bfin + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ + if !BR2_bfin && !BR2_x86_i386 depends on !(BR2_arc || BR2_xtensa) config BR2_UCLIBC_VERSION_ARC_GIT bool "uClibc Git ARC" + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD depends on BR2_arc config BR2_UCLIBC_NG_VERSION_1_0_0 bool "uClibc-ng 1.0.0" + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS \ + if BR2_arc || BR2_m68k + select BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD \ + if BR2_arc || BR2_bfin || BR2_m68k + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ + if !BR2_arc && !BR2_bfin && !BR2_x86_i386 config BR2_UCLIBC_VERSION_XTENSA_GIT bool "uClibc Git Xtensa" depends on BR2_xtensa + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS_OLD config BR2_UCLIBC_VERSION_SNAPSHOT bool "daily snapshot" + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS if !BR2_bfin && !BR2_xtensa + select BR2_UCLIBC_SUPPORTS_LINUXTHREADS_OLD + select BR2_UCLIBC_VERSION_SUPPORTS_NPTL \ + if !BR2_bfin && !BR2_x86_i386 && !BR2_xtensa depends on !(BR2_arc) endchoice @@ -101,8 +128,9 @@ config BR2_TOOLCHAIN_BUILDROOT_LOCALE choice prompt "Thread library implementation" - default BR2_PTHREADS_NATIVE if !BR2_xtensa - default BR2_PTHREADS_OLD + default BR2_PTHREADS_NATIVE if BR2_UCLIBC_VERSION_SUPPORTS_NPTL + default BR2_PTHREADS_OLD if BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD + default BR2_PTHREADS if BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS help Use this option to select the thread library implementation that should be used in your toolchain. Not all thread @@ -115,24 +143,19 @@ choice config BR2_PTHREADS bool "linuxthreads" - depends on !BR2_bfin - depends on !BR2_xtensa select BR2_TOOLCHAIN_HAS_THREADS + depends on BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS config BR2_PTHREADS_OLD bool "linuxthreads (stable/old)" select BR2_TOOLCHAIN_HAS_THREADS + depends on BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD config BR2_PTHREADS_NATIVE bool "Native POSIX Threading (NPTL)" select BR2_TOOLCHAIN_HAS_THREADS select BR2_TOOLCHAIN_HAS_THREADS_NPTL - depends on !BR2_arc - depends on !BR2_bfin - # There is NPTL support for Xtensa in uClibc-ng, but - # not in the main uClibc repository. - depends on !BR2_xtensa || !BR2_UCLIBC_VERSION_XTENSA_GIT - depends on !BR2_x86_i386 + depends on BR2_UCLIBC_VERSION_SUPPORTS_NPTL endchoice config BR2_PTHREAD_DEBUG
uClibc-ng does not support linuxthreads or linuxthreads.old on architectures that have NPTL support. This creates another complicated dependency: dependeing on the uClibc version being used, not the same thread implementations are available. In order to handle this situation, this patch introduces three hidden booleans: - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS - BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD - BR2_UCLIBC_VERSION_SUPPORTS_NPTL They are selected by the different uClibc versions, depending on which thread implementation they support on the different architectures. Then, the choice of the thread implementation can rely on those booleans to know if a given thread implementation is available in the current architecture / uClibc version selection. This makes sure that unusable thread implementation do not get selected, therefore fixing build issues such as: http://autobuild.buildroot.org/results/89e/89e423bee040cbce3e82cd89f1191efaac490c0d/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> --- package/uclibc/Config.in | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-)