Message ID | 1361455787-4846-1-git-send-email-gustavo@zacarias.com.ar |
---|---|
State | Accepted |
Commit | 6f786dcf7a8bda85b0095d76477c863338896656 |
Headers | show |
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Gustavo> This reverts commit 1d8c3e6caf6be14644ef8ef5ae2704105322442b
Gustavo> The forward port breaks compilation at least for SPARC NPTL
Gustavo> toolchains:
Committed, thanks.
Hi
I saw this patch was reverted, so I wonder is there (already or in the making) a way so I can point to a directory in the buildroot
configuration where I have additional µClibc patches and a 'series' file ? (similar like the infrastructure for the kernel patches.)
Annoying problem anyway, my app fails at runtime without the patch.
Johan
-----Oorspronkelijk bericht-----
Van: buildroot-bounces@busybox.net [mailto:buildroot-bounces@busybox.net] Namens Peter Korsgaard
Verzonden: donderdag 21 februari 2013 15:18
Aan: Gustavo Zacarias
CC: buildroot@busybox.net
Onderwerp: Re: [Buildroot] [PATCH] Revert "uClibc: port linuxthreads errnopatch to 0.9.33.2"
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
Gustavo> This reverts commit 1d8c3e6caf6be14644ef8ef5ae2704105322442b
Gustavo> The forward port breaks compilation at least for SPARC NPTL Gustavo> toolchains:
Committed, thanks.
--
Bye, Peter Korsgaard
On 02/22/2013 09:39 AM, Sagaert Johan wrote: > Hi > > I saw this patch was reverted, so I wonder is there (already or in the making) a way so I can point to a directory in the buildroot > configuration where I have additional µClibc patches and a 'series' file ? (similar like the infrastructure for the kernel patches.) > Annoying problem anyway, my app fails at runtime without the patch. > > Johan Hi. Out of curiosity why don't you want to use NPTL with the latest uClibc? If i remember correctly using anything other than NPTL is not recommended. You could use a trick similar to toolchain/gcc/*/powerpc-link-with-math-lib.patch.conditional for this patch but in a reverse fashion (the gcc patch is applied for powerpc only, you could apply for everything except sparc, though you'd had to check if it's the only affected arch - it's a build issue so it shouldn't be difficult). The patch conditions are set in toolchain/gcc/gcc-uclibc-4.x.mk Since the patch fixes issues i don't think Peter would disagree in applying it. Regards.
Hi It took some time till I could verify it against real hardware. I switched to NTPL and so far got no problems with any package. It's a bit mysterious when to use the other options (pthreads and pthreads old). Incompatible packages mostly do build, but the problems show up at runtime. Regards, Johan -----Oorspronkelijk bericht----- Van: Gustavo Zacarias [mailto:gustavo@zacarias.com.ar] Verzonden: vrijdag 22 februari 2013 13:44 Aan: Sagaert Johan CC: 'Peter Korsgaard'; buildroot@busybox.net Onderwerp: Re: [Buildroot] [PATCH] Revert "uClibc: port linuxthreads errnopatch to 0.9.33.2" On 02/22/2013 09:39 AM, Sagaert Johan wrote: > Hi > > I saw this patch was reverted, so I wonder is there (already or in the > making) a way so I can point to a directory in the buildroot > configuration where I have additional µClibc patches and a 'series' file ? (similar like the infrastructure for the kernel patches.) Annoying problem anyway, my app fails at runtime without the patch. > > Johan Hi. Out of curiosity why don't you want to use NPTL with the latest uClibc? If i remember correctly using anything other than NPTL is not recommended. You could use a trick similar to toolchain/gcc/*/powerpc-link-with-math-lib.patch.conditional for this patch but in a reverse fashion (the gcc patch is applied for powerpc only, you could apply for everything except sparc, though you'd had to check if it's the only affected arch - it's a build issue so it shouldn't be difficult). The patch conditions are set in toolchain/gcc/gcc-uclibc-4.x.mk Since the patch fixes issues i don't think Peter would disagree in applying it. Regards.
>>>>> "Sagaert" == Sagaert Johan <sagaert.johan@skynet.be> writes:
Sagaert> Hi
Sagaert> It took some time till I could verify it against real hardware.
Sagaert> I switched to NTPL and so far got no problems with any package.
Sagaert> It's a bit mysterious when to use the other options (pthreads
Sagaert> and pthreads old). Incompatible packages mostly do build, but
Sagaert> the problems show up at runtime.
The pthreads options are basically just there for legacy reasons (from
before NPTL existed) and presumably see very little testing these
days. We should aguable deprecate them.
On 03/04/13 20:51, Peter Korsgaard wrote: >>>>>> "Sagaert" == Sagaert Johan <sagaert.johan@skynet.be> writes: > > Sagaert> Hi > > Sagaert> It took some time till I could verify it against real hardware. > > Sagaert> I switched to NTPL and so far got no problems with any package. > > Sagaert> It's a bit mysterious when to use the other options (pthreads > Sagaert> and pthreads old). Incompatible packages mostly do build, but > Sagaert> the problems show up at runtime. > > The pthreads options are basically just there for legacy reasons (from > before NPTL existed) and presumably see very little testing these > days. We should aguable deprecate them. That would be a good idea. For who really wants it, there is still the crosstool-NG toolchain. Regards, Arnout
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: >> The pthreads options are basically just there for legacy reasons (from >> before NPTL existed) and presumably see very little testing these >> days. We should aguable deprecate them. Arnout> That would be a good idea. For who really wants it, there is Arnout> still the crosstool-NG toolchain. Yes. Unfortunately NPTL has a number of dependencies: depends on !BR2_UCLIBC_VERSION_0_9_31 depends on !BR2_ARM_OABI depends on !BR2_x86_i386 depends on !BR2_avr32 depends on !BR2_xtensa uClibc 0.9.31 and OABI are deprecated, so that's ok - but i386 (and generic, which is the same), avr32 and xtensa aren't. We could naturally mark pthread as depends on BR2_DEPRECATED if !(BR2_x86_i386 || BR2_avr32 || !BR2_xtensa) But that isn't very nice.
Hi Maybe setting the default uClibc-0.9.33.config to use NTPL would already be something to consider. Johan -----Oorspronkelijk bericht----- Van: Peter Korsgaard [mailto:jacmet@gmail.com] Namens Peter Korsgaard Verzonden: donderdag 7 maart 2013 9:53 Aan: Arnout Vandecappelle CC: Peter Korsgaard; Sagaert Johan; buildroot@busybox.net Onderwerp: Re: [PATCH] Revert "uClibc: port linuxthreads errnopatch to 0.9.33.2" >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: >> The pthreads options are basically just there for legacy reasons (from >> before NPTL existed) and presumably see very little testing these >> days. We should aguable deprecate them. Arnout> That would be a good idea. For who really wants it, there is Arnout> still the crosstool-NG toolchain. Yes. Unfortunately NPTL has a number of dependencies: depends on !BR2_UCLIBC_VERSION_0_9_31 depends on !BR2_ARM_OABI depends on !BR2_x86_i386 depends on !BR2_avr32 depends on !BR2_xtensa uClibc 0.9.31 and OABI are deprecated, so that's ok - but i386 (and generic, which is the same), avr32 and xtensa aren't. We could naturally mark pthread as depends on BR2_DEPRECATED if !(BR2_x86_i386 || BR2_avr32 || !BR2_xtensa) But that isn't very nice. -- Bye, Peter Korsgaard
Dear Sagaert Johan, On Thu, 7 Mar 2013 10:29:33 +0100, Sagaert Johan wrote: > Maybe setting the default uClibc-0.9.33.config to use NTPL would > already be something to consider. It's already the case. NPTL is the default when available. It's not directly visible in uClibc-0.9.33.config because Buildroot tweaks it before starting the uClibc build. See http://git.buildroot.net/buildroot/tree/toolchain/uClibc/uclibc.mk#n288. Thomas
On 22 February 2013 12:39, Sagaert Johan <sagaert.johan@skynet.be> wrote: > I saw this patch was reverted, so I wonder is there (already or in the making) a way so I can point to a directory in the buildroot > configuration where I have additional µClibc patches and a 'series' file ? (similar like the infrastructure for the kernel patches.) I realise that this discussion has moved on considerably since the original posting, but I just wanted to revive the idea of enabling support for custom patches for uClibc. I sent a patch a few weeks ago: http://patchwork.ozlabs.org/patch/222262/ but so far this has not received any feedback. For my workflow, using the internal Buildroot toolchain for avr32, this would be an extremely useful feature. Also, I feel that the patch is fairly innocuous. I'd appreciate any comments that people might have. Simon.
diff --git a/toolchain/uClibc/uClibc-0.9.33.2-linuxthreads-errno-fix.patch b/toolchain/uClibc/uClibc-0.9.33.2-linuxthreads-errno-fix.patch deleted file mode 100644 index c4d0d00..0000000 --- a/toolchain/uClibc/uClibc-0.9.33.2-linuxthreads-errno-fix.patch +++ /dev/null @@ -1,68 +0,0 @@ -From af8b2d71ce37b9d4d24ddbc755cdea68de02949a Mon Sep 17 00:00:00 2001 -From: Peter Korsgaard <jacmet@sunsite.dk> -Date: Mon, 5 Jul 2010 14:08:17 +0200 -Subject: [PATCH] don't make __errno_location / __h_errno_location hidden - -Closes #2089 (https://bugs.busybox.net/show_bug.cgi?id=2089) - -__errno_location / __h_errno_location access has to go through the PLT -like malloc/free, so the linuxthread variants gets used instead when -compiling with -pthread. - -Based on http://github.com/mat-c/uClibc/commit/328d392c54aa5dc2b8e7f398a419087de497de2b - -Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> ---- - include/netdb.h | 1 - - libc/misc/internals/__errno_location.c | 3 --- - libc/misc/internals/__h_errno_location.c | 1 - - libc/sysdeps/linux/common/bits/errno.h | 1 - - 6 files changed, 0 insertions(+), 11 deletions(-) - -diff --git a/include/netdb.h b/include/netdb.h -index 9d3807d..ac411ab 100644 ---- a/include/netdb.h -+++ b/include/netdb.h -@@ -59,7 +59,6 @@ __BEGIN_DECLS - - /* Function to get address of global `h_errno' variable. */ - extern int *__h_errno_location (void) __THROW __attribute__ ((__const__)); --libc_hidden_proto(__h_errno_location) - - /* Macros for accessing h_errno from inside libc. */ - #ifdef _LIBC -diff --git a/libc/misc/internals/__errno_location.c b/libc/misc/internals/__errno_location.c -index 487a9c2..0620860 100644 ---- a/libc/misc/internals/__errno_location.c -+++ b/libc/misc/internals/__errno_location.c -@@ -15,6 +15,3 @@ int * weak_const_function __errno_location (void) - { - return &errno; - } --#ifdef IS_IN_libc /* not really need, only to keep in sync w/ libc_hidden_proto */ --libc_hidden_weak(__errno_location) --#endif -diff --git a/libc/misc/internals/__h_errno_location.c b/libc/misc/internals/__h_errno_location.c -index 213d398..235df4e 100644 ---- a/libc/misc/internals/__h_errno_location.c -+++ b/libc/misc/internals/__h_errno_location.c -@@ -10,4 +10,3 @@ int * weak_const_function __h_errno_location (void) - { - return &h_errno; - } --libc_hidden_weak(__h_errno_location) -diff --git a/libc/misc/internals/__uClibc_main.c b/libc/misc/internals/__uClibc_main.c -index 6e520fa..f4a9ebb 100644 ---- a/libc/sysdeps/linux/common/bits/errno.h -+++ b/libc/sysdeps/linux/common/bits/errno.h -@@ -43,7 +43,6 @@ - # ifndef __ASSEMBLER__ - /* Function to get address of global `errno' variable. */ - extern int *__errno_location (void) __THROW __attribute__ ((__const__)); --libc_hidden_proto(__errno_location) - - # ifdef __UCLIBC_HAS_THREADS__ - /* When using threads, errno is a per-thread value. */ --- -1.7.1 -
This reverts commit 1d8c3e6caf6be14644ef8ef5ae2704105322442b The forward port breaks compilation at least for SPARC NPTL toolchains: LD libuClibc-0.9.33.2.so libc/libc_so.a(pipe.os): In function `__GI_pipe': (.text+0x38): undefined reference to `__GI___errno_location' collect2: ld returned 1 exit status Easily triggered by a "make qemu_sparc_ss10_defconfig && make". Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- .../uClibc-0.9.33.2-linuxthreads-errno-fix.patch | 68 ---------------------- 1 file changed, 68 deletions(-) delete mode 100644 toolchain/uClibc/uClibc-0.9.33.2-linuxthreads-errno-fix.patch