Rob Landley wrote: > On Sunday 26 October 2008 01:49:53 Carmelo Amoroso wrote: >> Rob Landley wrote: >>> On Wednesday 17 September 2008 06:29:34 Carmelo AMOROSO wrote: >>>> Search in the list for similar issues. I sugegsted a work-around in the >>>> past. I've got also a complete fix for uclibc, but up to now, never >>>> committed. >>>> >>>> Carmelo >>>> >>>> P.S. >>>> Please send emails in text/plain, not html >>> You say this while top-posting. :) >>> >>> Is your fix for uClibc, or uClibc++? This appears to be a uClibc++ >>> issue, how do you fix it in uClibc? >> Hi Rob, >> the fix is in uClibc, it consists of moving the implementation from ld.so >> and libdl.a to libc.so/libc.a. > > Could you give me a little more detail about exactly what the issue is? (Ok, > I read the patch, but "it breaks" and "this fixes it" doesn't really help me > form a good mental model of what's going on here...) > > The error message Flemming reported was trying to access a tls symbol, which > uClibc still doesn't support...? (Or is this a patch to the nptl branch?) > > Rob > Ok, I read the message of Flemming not carefully... the patch I proposed was referring to the dl_iterate_phdr missing symbols.
abi/libgcc_eh/unwind-dw2-fde-glibc.o: In function `_Unwind_Find_FDE': unwind-dw2-fde-glibc.c:(.text+0x17b8): undefined reference to `dl_iterate_phdr' Indeed, as he replied after my post, the reference to the __tls_get_addr function was due a configuration error of uClibc++. Sorry for having confused with multiple patches/proposal and emails. Currently the dl_iterate_phdr symbols is defined in ld-uClibc.so.0 and libdl.a. The idea is to move into libc.so.0 and libc.a (exactly as glibc does). Carmelo _______________________________________________ > uClibc mailing list > uClibc@uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc