| Message ID | 1425415991-20530-1-git-send-email-gustavo@zacarias.com.ar |
|---|---|
| State | Rejected |
| Headers | show |
>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > Is broken like plain uClibc, fixes: > http://autobuild.buildroot.net/results/77f/77fe89d358a90f5167e58bedb73495d7ee9a7f5d/ So why do we have: commit 060125b4fed11458288b14fbd2d49e1c12eb11df Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Date: Sat Feb 14 22:01:07 2015 +0100 uclibc: enable Xtensa NPTL support with uClibc-ng Then? Presumably something was working when this was done?
On 03/03/2015 06:26 PM, Peter Korsgaard wrote: >>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > > > Is broken like plain uClibc, fixes: > > http://autobuild.buildroot.net/results/77f/77fe89d358a90f5167e58bedb73495d7ee9a7f5d/ > > So why do we have: > > commit 060125b4fed11458288b14fbd2d49e1c12eb11df > Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Date: Sat Feb 14 22:01:07 2015 +0100 > > uclibc: enable Xtensa NPTL support with uClibc-ng > > Then? Presumably something was working when this was done? Autobuilders are speaking up, i gave uclibc a quick look and xtensa elfinterp.c is the only arch including dl-tls.h I'll try droppping that, it doesn't make sense that the interpreter needs tls, but for the time being i'd nuke uclibc-ng for xtensa pending testing/upstream aproval. Regards.
On 03/03/2015 06:32 PM, Gustavo Zacarias wrote: > On 03/03/2015 06:26 PM, Peter Korsgaard wrote: > >>>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: >> >> > Is broken like plain uClibc, fixes: >> > http://autobuild.buildroot.net/results/77f/77fe89d358a90f5167e58bedb73495d7ee9a7f5d/ >> >> So why do we have: >> >> commit 060125b4fed11458288b14fbd2d49e1c12eb11df >> Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> >> Date: Sat Feb 14 22:01:07 2015 +0100 >> >> uclibc: enable Xtensa NPTL support with uClibc-ng >> >> Then? Presumably something was working when this was done? > > Autobuilders are speaking up, i gave uclibc a quick look and xtensa > elfinterp.c is the only arch including dl-tls.h > I'll try droppping that, it doesn't make sense that the interpreter > needs tls, but for the time being i'd nuke uclibc-ng for xtensa pending > testing/upstream aproval. > Regards. Digging up a little more the scenario is: uclibc-ng -> nptl (old threads broken, none possibly as well) uclibc -> no nptl, only old or none. So basically apply the patch i say, it's not an option we had shipping and uclibc-ng git reverts (and re-reverts!) this so we should wait for a new release to know what's up and let them make up their mind. Regards.
Hi, Gustavo Zacarias wrote, > On 03/03/2015 06:32 PM, Gustavo Zacarias wrote: > > > On 03/03/2015 06:26 PM, Peter Korsgaard wrote: > > > >>>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes: > >> > >> > Is broken like plain uClibc, fixes: > >> > http://autobuild.buildroot.net/results/77f/77fe89d358a90f5167e58bedb73495d7ee9a7f5d/ > >> > >> So why do we have: > >> > >> commit 060125b4fed11458288b14fbd2d49e1c12eb11df > >> Author: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > >> Date: Sat Feb 14 22:01:07 2015 +0100 > >> > >> uclibc: enable Xtensa NPTL support with uClibc-ng > >> > >> Then? Presumably something was working when this was done? > > > > Autobuilders are speaking up, i gave uclibc a quick look and xtensa > > elfinterp.c is the only arch including dl-tls.h > > I'll try droppping that, it doesn't make sense that the interpreter > > needs tls, but for the time being i'd nuke uclibc-ng for xtensa pending > > testing/upstream aproval. > > Regards. > > Digging up a little more the scenario is: > uclibc-ng -> nptl (old threads broken, none possibly as well) > uclibc -> no nptl, only old or none. The analysis is correct. uClibc-ng only support NPTL or NONE for NPTL supported architectures like ARM, PPC, MIPS, X86, XTENSA, ... It will only support LT.old for BFIN, CRIS, ARM-NOMMU, M68k/Coldfire, .. > So basically apply the patch i say, it's not an option we had shipping > and uclibc-ng git reverts (and re-reverts!) this so we should wait for a > new release to know what's up and let them make up their mind. Sorry for the revert stuff. It was an accident while testing some pthread static linking stuff with cdrkit. I didn't want to push these changes, just some inability on my site to work with branches and multiple checkouts ;) Please don't apply this patch. I will sent a patch, so that XTENSA and other NPTL architectures can not be configured to use LT.old or LT.new in Buildroot. best regards Waldemar
On 03/04/2015 07:55 AM, Waldemar Brodkorb wrote: > The analysis is correct. uClibc-ng only support NPTL or NONE for > NPTL supported architectures like ARM, PPC, MIPS, X86, XTENSA, ... > It will only support LT.old for BFIN, CRIS, ARM-NOMMU, > M68k/Coldfire, .. Yes, but... > Sorry for the revert stuff. It was an accident while testing some > pthread static linking stuff with cdrkit. I didn't want to push > these changes, just some inability on my site to work with branches > and multiple checkouts ;) > > Please don't apply this patch. I will sent a patch, so that > XTENSA and other NPTL architectures can not be configured to use > LT.old or LT.new in Buildroot. Kconfig logic as we spoke on IRC is working fine, it's falling back to none. The problem is that none is broken, all that TLS stuff doesn't belong in ldso/elfinterp. Regards.
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in index 3a65752..11a4ba2 100644 --- a/package/uclibc/Config.in +++ b/package/uclibc/Config.in @@ -23,6 +23,7 @@ choice config BR2_UCLIBC_NG_VERSION_1_0_0 bool "uClibc-ng 1.0.0" + depends on !BR2_xtensa config BR2_UCLIBC_VERSION_XTENSA_GIT bool "uClibc Git Xtensa"
Is broken like plain uClibc, fixes: http://autobuild.buildroot.net/results/77f/77fe89d358a90f5167e58bedb73495d7ee9a7f5d/ Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> --- package/uclibc/Config.in | 1 + 1 file changed, 1 insertion(+)