Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2011-12-01 Thread Carmelo AMOROSO
On 30/11/2011 22.44, Khem Raj wrote: > On Wed, Nov 30, 2011 at 5:57 AM, Carmelo AMOROSO > wrote: >> On 29/11/2011 17.18, Khem Raj wrote: >>> On Tue, Nov 29, 2011 at 1:53 AM, Carmelo AMOROSO >>> wrote: On 28/11/2011 18.33, Khem Raj wrote: > On Mon, Nov 28, 2011 at 5:21 AM, Carmelo AMORO

Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2011-12-01 Thread Carmelo AMOROSO
On 30/11/2011 22.44, Khem Raj wrote: > On Wed, Nov 30, 2011 at 5:57 AM, Carmelo AMOROSO > wrote: >> On 29/11/2011 17.18, Khem Raj wrote: >>> On Tue, Nov 29, 2011 at 1:53 AM, Carmelo AMOROSO >>> wrote: On 28/11/2011 18.33, Khem Raj wrote: > On Mon, Nov 28, 2011 at 5:21 AM, Carmelo AMORO

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Peter Mazinger
hi > __errno_location() function should not be library-wide hidden in > non-TLS (thread local storage) case since it should be overriden > by thread-aware function from linuxthreads.old/linuxthreads. > If the function is hidden, calls from libc itself always use it > regardless libpthread linked o

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Andrew Rybchenko
Hi Peter, On 12/01/2011 06:35 PM, Peter Mazinger wrote: hi __errno_location() function should not be library-wide hidden in non-TLS (thread local storage) case since it should be overriden by thread-aware function from linuxthreads.old/linuxthreads. If the function is hidden, calls from libc i

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Peter Korsgaard
> "Andrew" == Andrew Rybchenko writes: Hi, Andrew> linuxthreads.old implementation just wraps libc socket calls like Andrew> recv() which set errno. Andrew> Since errno is set from libc call and libc_hidden_proto() is used for Andrew> __errno_location(), Andrew> libc version of the func

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Andrew Rybchenko
Hi Peter, On 12/01/2011 07:36 PM, Peter Korsgaard wrote: "Andrew" == Andrew Rybchenko writes: Hi, Andrew> linuxthreads.old implementation just wraps libc socket calls like Andrew> recv() which set errno. Andrew> Since errno is set from libc call and libc_hidden_proto() is used for

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Peter Korsgaard
> "Andrew" == Andrew Rybchenko writes: Hi, >> Sounds related to: >> >> https://bugs.busybox.net/show_bug.cgi?id=2089 Andrew> Yes, it is definitely related. I don't understand why the bug Andrew> is RESOLVED as WONTFIX. Of course it is nice that it is not an Andrew> issue with NPTL, b

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread u-uclibc-y2lt
On Thu, Dec 01, 2011 at 07:52:37PM +0400, Andrew Rybchenko wrote: > The bug makes uClibc 0.9.32 as well as 0.9.31 unusable with > linuxthreads.old. I've not checked linuxthreads. IMHO, it would be > really nice if it is finally fixed in upcoming releases. +1 (have to patch here on our own) Rune

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Peter Mazinger
Hi On 12/01/2011 06:35 PM, Peter Mazinger wrote: > > hi > > > >> __errno_location() function should not be library-wide hidden in > >> non-TLS (thread local storage) case since it should be overriden > >> by thread-aware function from linuxthreads.old/linuxthreads. > >> If the function is hidden,

Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2011-12-01 Thread Khem Raj
>> yes I tried the elf_machine_relocations patch and it did not help >> I am at 7682323a3a798d6f15708f228f859a64cb869aa3 >> which is merge commit. >> > > so if you do reset --hard HEAD~1 you have something working again ? > yes ___ uClibc mailing list uC

Re: [PATCH] fix errno location for non-TLS case

2011-12-01 Thread Andrew Rybchenko
Hi Peter, On 12/01/2011 11:09 PM, Peter Mazinger wrote: On 12/01/2011 06:35 PM, Peter Mazinger wrote: > libc_hidden_proto does not hide __errno_location, it hides in reality __GI___errno_location Yes, exactly. I'm afraid "hidden" term is brought here from GCC and a bit confusing/misleading. A