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

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

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

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

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.

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

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

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.

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