[Buildroot] [PATCH 0/3] uClibc-ng related fixes

[Buildroot] [PATCH 0/3] uClibc-ng related fixes

[Thomas Petazzoni]

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

-- 
2.1.0

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

[Thomas Petazzoni]

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(-)

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
-- 
2.1.0

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

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Waldemar Brodkorb]

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

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

[Thomas Petazzoni]

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 Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Alexey Brodkin]

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

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Yann E. MORIN]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Waldemar Brodkorb]

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

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

[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 <thomas.petazzoni@free-electrons.com>
---
 package/uclibc/Config.in | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
index c66373d..1839d65 100644
--- a/package/uclibc/Config.in
+++ b/package/uclibc/Config.in
@@ -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"
-- 
2.1.0

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

[Yann E. MORIN]

Thomas, All,

On 2015-03-07 14:39 +0100, Thomas Petazzoni spake thusly:
> 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 <thomas.petazzoni@free-electrons.com>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/uclibc/Config.in | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
> index c66373d..1839d65 100644
> --- a/package/uclibc/Config.in
> +++ b/package/uclibc/Config.in
> @@ -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"
> -- 
> 2.1.0
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

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

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../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

diff --git a/package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch b/package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
new file mode 100644
index 0000000..33f876b
--- /dev/null
+++ b/package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
@@ -0,0 +1,49 @@
+From bc8a6a6d8075998f0d1563cf202dcc18c39974b3 Mon Sep 17 00:00:00 2001
+From: Waldemar Brodkorb <wbx@openadk.org>
+Date: Thu, 5 Mar 2015 19:47:26 +0100
+Subject: [PATCH 2/2] fix non-thread compile for xtensa
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+---
+ 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
+
-- 
2.1.0

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

[Yann E. MORIN]

Thomas, All,

On 2015-03-07 14:40 +0100, Thomas Petazzoni spake thusly:
> Backported from upstream, will be part of the next release of
> uClibc-ng.
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  .../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" <yann.morin.1998@free.fr>

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

Regards,
Yann E. MORIN.

>  1 file changed, 49 insertions(+)
>  create mode 100644 package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
> 
> diff --git a/package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch b/package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
> new file mode 100644
> index 0000000..33f876b
> --- /dev/null
> +++ b/package/uclibc/1.0.0/0002-fix-non-thread-compile-for-xtensa.patch
> @@ -0,0 +1,49 @@
> +From bc8a6a6d8075998f0d1563cf202dcc18c39974b3 Mon Sep 17 00:00:00 2001
> +From: Waldemar Brodkorb <wbx@openadk.org>
> +Date: Thu, 5 Mar 2015 19:47:26 +0100
> +Subject: [PATCH 2/2] fix non-thread compile for xtensa
> +
> +Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> +---
> + 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
> +
> -- 
> 2.1.0
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Waldemar Brodkorb]

Hi Yann,
Yann E. MORIN wrote,

> Thomas, All,
> 
> On 2015-03-07 14:40 +0100, Thomas Petazzoni spake thusly:
> > Backported from upstream, will be part of the next release of
> > uClibc-ng.
> > 
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > ---
> >  .../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
 

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

[Yann E. MORIN]

On 2015-03-07 16:43 +0100, Waldemar Brodkorb spake thusly:
> Yann E. MORIN wrote,
> > On 2015-03-07 14:40 +0100, Thomas Petazzoni spake thusly:
> > > Backported from upstream, will be part of the next release of
> > > uClibc-ng.
> > > 
> > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > > ---
> > >  .../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?

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

Dear Waldemar Brodkorb,

On Sat, 7 Mar 2015 16:43:26 +0100, Waldemar Brodkorb wrote:

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

> 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Waldemar Brodkorb]

Hi Thomas,
Thomas Petazzoni wrote,

> Dear Waldemar Brodkorb,
> 
> On Sat, 7 Mar 2015 16:43:26 +0100, Waldemar Brodkorb wrote:
> 
> > 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.

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.

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

[Thomas Petazzoni]

Dear Waldemar Brodkorb,

On Sat, 7 Mar 2015 18:56:51 +0100, Waldemar Brodkorb wrote:

> > 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sat, 7 Mar 2015 15:40:13 +0100, Yann E. MORIN wrote:

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

> (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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com