arm-oabi and mips and such not building for me with NPTL.

Rob Landley rob at landley.net
Sat Mar 19 02:36:21 UTC 2011


On 03/18/2011 09:51 AM, Peter Mazinger wrote:
> Hi Rob
> 
>> So the NPTL versions of i686 and arm-eabi build with the same invocation
>> pthreads.old used, but none of the other targets I've tried do.  Instead
>> those fail with:
>>
>> libpthread/nptl/libpthread_so.a(pthread_once.oS): In function
>> `__pthread_once_internal':
>> pthread_once.c:(.text+0x78): undefined reference to
>> `_Unwind_SjLj_Register'
>> libpthread/nptl/libpthread_so.a(pthread_once.oS): In function `.L15':
>> pthread_once.c:(.text+0x164): undefined reference to `_Unwind_SjLj_Resume'
>> pthread_once.c:(.text+0x16c): undefined reference to
>> `_Unwind_SjLj_Unregister'
>> pthread_once.c:(.text+0x180): undefined reference to
>> `__gcc_personality_sj0'
>> collect2: ld returned 1 exit status
> 
> if that is missing from libgcc*, you might want to compile gcc with
> --enable-sjlj-exceptions

I did.  I also compiled it with --disable-shared since it's a stage 1
compiler, so the code wound up in libgcc_eh.a.

I build a stage 1 compiler, then build the target system (busybox,
uClibc, and a native toolchain) with that.  None of that actually needs
thread support, but uClibc needs to exist before building a stage 2
compiler (so it can link libgcc_s.so against it).

Previously I was building uClibc once and it always worked fine.  (The
stack unwinding code is actually used these days by setjmp/longjmp so it
needs to be present as part of most toolchains.)  Unfortunately, the
uClibc build sequence for NPTL is manually overriding the toolchain's
normal link stuff but isn't including libgcc_eh.a, and when I patch it
in (which I'm willing to do at this end), it conflicts with a symbol
that libpthread_so.a redundantly implements.

The weird part is that the old build sequence still works fine,
unmodified, for arm-eabi and i686, even with NPTL...

> Peter

Rob


More information about the uClibc mailing list