Skip to contentSkip to conversation

uClibc-ng related fixes

PATCH Superseded Thomas Petazzoni 4 participants 22 messages Mar 7, 2015 – Mar 9, 2015

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Thomas Petazzoni

author
#0 lore raw

cover uClibc-ng related fixes

Hello,

This patch series is a proposal to solve the same problem as
http://patchwork.ozlabs.org/patch/446288/ but in an hopefully nicer way (first patch).

The other two patches are related improvements/fixes.

Thanks,

Thomas

Thomas Petazzoni (3):
uclibc: adapt thread implementation selection to uClibc-ng
uclibc: remove bogus comment about thread implementation selection
uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng

    1.0.0
 .../0002-fix-non-thread-compile-for-xtensa.patch   | 49 ++++++++++++++++++++++
 package/uclibc/Config.in                           | 48 ++++++++++++++-------
 2 files changed, 83 insertions(+), 14 deletions(-)
 create mode 100644 package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
Signature · 1 line
2.1.0
author
#1 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

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 <[email protected]>
---
 package/uclibc/Config.in | 43 +++++++++++++++++++++++++++++++++----------
 1 file changed, 33 insertions(+), 10 deletions(-)
package/uclibc/Config.in +33 -10
index 3a65752..c66373d 100644
@@ -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
Signature · 1 line
2.1.0
#2 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Thomas, All,

On 2015-03-07 14:39 +0100, Thomas Petazzoni spake thusly:

Quoted 19 lines

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.

Quoted 6 lines

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 <[email protected]>
Reviewed-by "Yann E. MORIN" <[email protected]>

However, a small comment, see below...

Quoted 39 lines
---
 package/uclibc/Config.in | 43 +++++++++++++++++++++++++++++++++----------
 1 file changed, 33 insertions(+), 10 deletions(-)
package/uclibc/Config.in +16 -0
index 3a65752..c66373d 100644
@@ -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

package/uclibc/Config.in choice · line 47

Quoted 10 lines
package/uclibc/Config.in +6 -0
 		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. ;-)

package/uclibc/Config.in choice · line 52

Quoted 4 lines
package/uclibc/Config.in +1 -0
 	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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#3 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Dear Yann E. MORIN,

Quoted 10 lines · Yann E. MORIN

package/uclibc/Config.in choice · line 47

Quoted 8 lines
package/uclibc/Config.in +6 -0
 	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).

Quoted 5 lines

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#4 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

In reply to Thomas Petazzoni

Hi Thomas,
Thomas Petazzoni wrote,

Quoted 12 lines

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

Quoted 6 lines

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

author
#5 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Waldemar, Alexey,

Quoted 6 lines · Waldemar Brodkorb

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#6 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Hi Thomas,

Quoted 8 lines · Thomas Petazzoni

Waldemar, Alexey,

Quoted 4 lines · Waldemar Brodkorb

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

Quoted 8 lines
Quoted 2 lines

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

author
#7 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Dear Alexey Brodkin,

Quoted 17 lines · Alexey Brodkin

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.

Quoted 6 lines

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#8 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

In reply to Thomas Petazzoni

Thomas, All,

On 2015-03-07 14:39 +0100, Thomas Petazzoni spake thusly:

Quoted 19 lines

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.

Quoted 6 lines

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 <[email protected]>

Here's a further review, since you asked for it... ;-)

Quoted 13 lines
package/uclibc/Config.in +7 -0
 	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

package/uclibc/Config.in choice · line 47

Quoted 10 lines
package/uclibc/Config.in +6 -0
 		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.

Quoted 61 lines
package/uclibc/Config.in +11 -10
 	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
Signature · 6 lines
2.1.0

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#9 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Dear Yann E. MORIN,

Quoted 11 lines · Yann E. MORIN

package/uclibc/Config.in choice · line 47

Quoted 8 lines
package/uclibc/Config.in +6 -0
 	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 :

Quoted 2 lines
                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.

Quoted 1 line

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.

Quoted 1 line

bfin Y Y -

Correct. That needs to be fixed in my patch.

Quoted 13 lines
    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
Quoted 8 lines

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#10 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Thomas, All,

On 2015-03-08 08:40 +0100, Thomas Petazzoni spake thusly:

Quoted 20 lines · Yann E. MORIN
Quoted 11 lines

package/uclibc/Config.in choice · line 47

Quoted 8 lines
package/uclibc/Config.in +6 -0
 	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 :

Quoted 2 lines
                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.

Quoted 6 lines
Quoted 1 line

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. ;-)

Quoted 26 lines
Quoted 1 line

bfin Y Y -

Correct. That needs to be fixed in my patch.

Quoted 13 lines
    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
Quoted 8 lines

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
Quoted 2 lines

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.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#11 lore raw

PATCH 1/3 uclibc: adapt thread implementation selection to uClibc-ng

Hi,
Yann E. MORIN wrote,

Quoted 4 lines

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

author
#12 lore raw

PATCH 2/3 uclibc: remove bogus comment about thread implementation selection

In reply to Thomas Petazzoni

There is no need to warn the user about selecting an inappropriate thread implementation, since we make sure only supported combinations can be selected.

Signed-off-by Thomas Petazzoni <[email protected]>
---
 package/uclibc/Config.in | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
package/uclibc/Config.in +1 -4
index c66373d..1839d65 100644
@@ -133,10 +133,7 @@ choice
 	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
-	  variants work with all versions of uClibc, the "linuxthreads
-	  (stable/old)" may be a working fallback if you need
-	  threading at all.
+	  that should be used in your toolchain.
 
 	config BR2_PTHREADS_NONE
 		bool "none"
Signature · 1 line
2.1.0
#13 lore raw

PATCH 2/3 uclibc: remove bogus comment about thread implementation selection

Thomas, All,

On 2015-03-07 14:39 +0100, Thomas Petazzoni spake thusly:

Quoted 5 lines

There is no need to warn the user about selecting an inappropriate thread implementation, since we make sure only supported combinations can be selected.

Signed-off-by Thomas Petazzoni <[email protected]>
Acked-by "Yann E. MORIN" <[email protected]>

Regards,
Yann E. MORIN.

Quoted 27 lines
---
 package/uclibc/Config.in | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
package/uclibc/Config.in +1 -4
index c66373d..1839d65 100644
@@ -133,10 +133,7 @@ choice
 	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
-	  variants work with all versions of uClibc, the "linuxthreads
-	  (stable/old)" may be a working fallback if you need
-	  threading at all.
+	  that should be used in your toolchain.
 
 	config BR2_PTHREADS_NONE
 		bool "none"
Signature · 6 lines
2.1.0

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#14 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

In reply to Thomas Petazzoni

Backported from upstream, will be part of the next release of uClibc-ng.

Signed-off-by Thomas Petazzoni <[email protected]>
---
 .../0002-fix-non-thread-compile-for-xtensa.patch   | 49 ++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch new file +49 -0
new file mode 100644
index 0000000..33f876b
@@ -0,0 +1,49 @@
+From bc8a6a6d8075998f0d1563cf202dcc18c39974b3 Mon Sep 17 00:00:00 2001
+From: Waldemar Brodkorb <[email protected]>
+Date: Thu, 5 Mar 2015 19:47:26 +0100
+Subject: [PATCH 2/2] fix non-thread compile for xtensa
+
+Signed-off-by: Thomas Petazzoni <[email protected]>
+---
+ ldso/ldso/xtensa/dl-tlsdesc.S | 4 ++++
+ ldso/ldso/xtensa/elfinterp.c  | 3 +++
+ 2 files changed, 7 insertions(+)
+
+diff --git a/ldso/ldso/xtensa/dl-tlsdesc.S b/ldso/ldso/xtensa/dl-tlsdesc.S
+index a6ebc94..dee4258 100644
+--- a/ldso/ldso/xtensa/dl-tlsdesc.S
++++ b/ldso/ldso/xtensa/dl-tlsdesc.S
+@@ -18,6 +18,9 @@
+ 
+ #include <sysdep.h>
+ #include <tls.h>
++
++#if defined(USE_TLS) && USE_TLS
++
+ #include "tlsdesc.h"
+ 
+ 
+@@ -94,3 +97,4 @@ _dl_tlsdesc_dynamic:
+ 	.size	_dl_tlsdesc_dynamic, .-_dl_tlsdesc_dynamic
+ 
+ #endif /* SHARED */
++#endif /* USE_TLS */
+diff --git a/ldso/ldso/xtensa/elfinterp.c b/ldso/ldso/xtensa/elfinterp.c
+index 1397e95..66deb63 100644
+--- a/ldso/ldso/xtensa/elfinterp.c
++++ b/ldso/ldso/xtensa/elfinterp.c
+@@ -31,8 +31,11 @@
+  */
+ 
+ #include "ldso.h"
++
++#if defined(USE_TLS) && USE_TLS
+ #include "dl-tls.h"
+ #include "tlsdeschtab.h"
++#endif
+ 
+ unsigned long
+ _dl_linux_resolver (struct elf_resolve *tpnt, int reloc_entry)
+-- 
+2.1.0
+
Signature · 1 line
2.1.0
#15 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

Thomas, All,

On 2015-03-07 14:40 +0100, Thomas Petazzoni spake thusly:

Quoted 6 lines

Backported from upstream, will be part of the next release of uClibc-ng.

Signed-off-by Thomas Petazzoni <[email protected]>
---
 .../0002-fix-non-thread-compile-for-xtensa.patch   | 49 ++++++++++++++++++++++

I know this is not the first patch we have against uClibc-ng, but what will happen when uClibc eventually tags 1.0.0? How will we differentiate the patch directories between uClibc-1.0.0 and uClibc-ng 1.0.0 ?

(or for any other version, for what it's worth...)

Reviewed-by "Yann E. MORIN" <[email protected]>

(BTW, there's no bc8a6a6 commit upstream, it's b15663c)

Regards,
Yann E. MORIN.

Quoted 65 lines
 1 file changed, 49 insertions(+)
 create mode 100644 package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch new file +49 -0
new file mode 100644
index 0000000..33f876b
@@ -0,0 +1,49 @@
+From bc8a6a6d8075998f0d1563cf202dcc18c39974b3 Mon Sep 17 00:00:00 2001
+From: Waldemar Brodkorb <[email protected]>
+Date: Thu, 5 Mar 2015 19:47:26 +0100
+Subject: [PATCH 2/2] fix non-thread compile for xtensa
+
+Signed-off-by: Thomas Petazzoni <[email protected]>
+---
+ ldso/ldso/xtensa/dl-tlsdesc.S | 4 ++++
+ ldso/ldso/xtensa/elfinterp.c  | 3 +++
+ 2 files changed, 7 insertions(+)
+
+diff --git a/ldso/ldso/xtensa/dl-tlsdesc.S b/ldso/ldso/xtensa/dl-tlsdesc.S
+index a6ebc94..dee4258 100644
+--- a/ldso/ldso/xtensa/dl-tlsdesc.S
++++ b/ldso/ldso/xtensa/dl-tlsdesc.S
+@@ -18,6 +18,9 @@
+ 
+ #include <sysdep.h>
+ #include <tls.h>
++
++#if defined(USE_TLS) && USE_TLS
++
+ #include "tlsdesc.h"
+ 
+ 
+@@ -94,3 +97,4 @@ _dl_tlsdesc_dynamic:
+ 	.size	_dl_tlsdesc_dynamic, .-_dl_tlsdesc_dynamic
+ 
+ #endif /* SHARED */
++#endif /* USE_TLS */
+diff --git a/ldso/ldso/xtensa/elfinterp.c b/ldso/ldso/xtensa/elfinterp.c
+index 1397e95..66deb63 100644
+--- a/ldso/ldso/xtensa/elfinterp.c
++++ b/ldso/ldso/xtensa/elfinterp.c
+@@ -31,8 +31,11 @@
+  */
+ 
+ #include "ldso.h"
++
++#if defined(USE_TLS) && USE_TLS
+ #include "dl-tls.h"
+ #include "tlsdeschtab.h"
++#endif
+ 
+ unsigned long
+ _dl_linux_resolver (struct elf_resolve *tpnt, int reloc_entry)
+-- 
+2.1.0
+
Signature · 6 lines
2.1.0

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#16 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

Hi Yann,
Yann E. MORIN wrote,

Quoted 6 lines

Thomas, All,

On 2015-03-07 14:40 +0100, Thomas Petazzoni spake thusly:

Quoted 3 lines

Backported from upstream, will be part of the next release of uClibc-ng.

Quoted 7 lines
Quoted 3 lines
Signed-off-by Thomas Petazzoni <[email protected]>
---
 .../0002-fix-non-thread-compile-for-xtensa.patch   | 49 ++++++++++++++++++++++

I know this is not the first patch we have against uClibc-ng, but what will happen when uClibc eventually tags 1.0.0? How will we differentiate the patch directories between uClibc-1.0.0 and uClibc-ng 1.0.0 ?

May be then we get an extra package for uClibc-ng? Bernhard is planning 0.9.34 release, so it is more a theoretically problem. I am sure uClibc-ng 1.1 is out before uClibc tags 1.0.0.

best regards
Waldemar

#17 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

On 2015-03-07 16:43 +0100, Waldemar Brodkorb spake thusly:

Quoted 9 lines

Yann E. MORIN wrote,

Quoted 8 lines

On 2015-03-07 14:40 +0100, Thomas Petazzoni spake thusly:

Quoted 6 lines

Backported from upstream, will be part of the next release of uClibc-ng.

Signed-off-by Thomas Petazzoni <[email protected]>
---
 .../0002-fix-non-thread-compile-for-xtensa.patch   | 49 ++++++++++++++++++++++
Quoted 5 lines
Quoted 3 lines

I know this is not the first patch we have against uClibc-ng, but what will happen when uClibc eventually tags 1.0.0? How will we differentiate the patch directories between uClibc-1.0.0 and uClibc-ng 1.0.0 ?

May be then we get an extra package for uClibc-ng?

Well, uClibc-ng is still too similar to uClibc to warrant a different package. That's the whole point Thomas argued for in the previous attempts at adding uClibc-ng.

We could make the version string something like "ng-1.0.0"... That's a bit of a hack, however.

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#18 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

In reply to Waldemar Brodkorb

Dear Waldemar Brodkorb,

Quoted 1 line · Waldemar Brodkorb

May be then we get an extra package for uClibc-ng?

No, I'm still not convinced we need separate packages at this point. Maybe in the future if uClibc and uClibc-ng diverge significantly, but it's not the case right now.

Quoted 2 lines

Bernhard is planning 0.9.34 release, so it is more a theoretically problem. I am sure uClibc-ng 1.1 is out before uClibc tags 1.0.0.

I'll wait for real acts from Bernhard before presuming that something will happen in uClibc land. It may very well that we'll get rid of uClibc support entirely in favor of uClibc-ng before Bernhard gets to doing a new release for uClibc.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#19 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

Hi Thomas,
Thomas Petazzoni wrote,

Quoted 5 lines

Dear Waldemar Brodkorb,

Quoted 1 line · Waldemar Brodkorb

May be then we get an extra package for uClibc-ng?

           ^^^^
Quoted 3 lines

No, I'm still not convinced we need separate packages at this point. Maybe in the future if uClibc and uClibc-ng diverge significantly, but it's not the case right now.

To clear things up, I am happy with the version stuff and we don't need an extra package. I just thought whenever we get the situation that uClibc 1.0.0 is released _and_ uClibc-ng is still using 1.0.x ;)

best regards

Waldemar

I shut up now.

author
#20 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

Dear Waldemar Brodkorb,

Quoted 8 lines · Waldemar Brodkorb
Quoted 3 lines

No, I'm still not convinced we need separate packages at this point. Maybe in the future if uClibc and uClibc-ng diverge significantly, but it's not the case right now.

To clear things up, I am happy with the version stuff and we don't need an extra package. I just thought whenever we get the situation that uClibc 1.0.0 is released _and_ uClibc-ng is still using 1.0.x ;)

Ah, yes indeed. If/when this situation arises, having separate packages would be a solution.

Again, I guess it's too early to really draw a plan about what will happen between uClibc and uClibc-ng. It really all depends on how both projects will be maintained: if you continue to be active on uClibc-ng or not, if the original uClibc project moves again or not, etc. So let's not make too much plans, and see what happens :-)

However, one plan I'd like to make is to make uClibc-ng the default uClibc version. Maybe for 2015.05, if not for 2015.08.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#21 lore raw

PATCH 3/3 uclibc: add patch fixing non-threaded build on Xtensa for uClibc-ng 1.0.0

In reply to Yann E. MORIN

Dear Yann E. MORIN,

Quoted 3 lines · Yann E. MORIN

I know this is not the first patch we have against uClibc-ng, but what will happen when uClibc eventually tags 1.0.0? How will we differentiate the patch directories between uClibc-1.0.0 and uClibc-ng 1.0.0 ?

I thought about this, and one idea would be to have the version named "ng-1.0.0" for the point of view of Buildroot, so that instead of using uClibc-ng-$(UCLIBC_VERSION) or uClibc-$(UCLIBC_VERSION).

Quoted 1 line

(BTW, there's no bc8a6a6 commit upstream, it's b15663c)

bc8a6a6 is the commit ID once cherry-picked on top of a branch based on v1.0.0, with the other uClibc-ng patch applied.

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com