Mike Frysinger wrote: > On Friday 11 January 2008, Carmelo AMOROSO wrote: >> I'm facing a problem when statically linking an app with >> sh4-linux-uclibc-g++ >> caused by the missing symbol dl_iterate_phdr as below: >> >> sh4-linux-uclibc-g++ -static main.c >> /opt/STM/STLinux-2.3/devkit/sh4_uclibc/lib/gcc/sh4-linux-uclibc/4.2.1/libgc >> c_eh.a(unwind-dw2-fde-glibc.o): In function `_Unwind_Find_FDE': >> /home/macaroni/users/products/stm2.3/build/packages/stm-cross-gcc-sh4_uclib >> c/BUILD/gcc-4.2.1/objdir/gcc/../../gcc/unwind-dw2-fde-glibc.c:430: undefined >> reference to `dl_iterate_phdr' > > static is the devil ;) Hi Mike, yes, but it seems a lot of people in embedded world prefer it, likely they have concerns on performance.
> >> Indeed the symbols is defined into the ld.so (not used when statically >> linked) and into libdl.a > > yep > >> but, being libgcc_eh.a requiring this symbol, it will not find it even >> if -ldl is passed. > > what a pain huh > >> I've checked glibc and found that dl_iterate_phdr in into libc instead >> od ld.so and libdl.a >> A comment in uclibc dl-elf.c says explicitly: >> >> "we want this in ld.so and libdl.a but nowhere else" >> >> Could someone explain this to me ? > > it's a symbol only used by symbol related stuff which is why we put it there. > > the comment is to cover the fact we *dont* want it in say libdl.so. > >> I need to fix immediately into uclibc-nptl sh4 > > isnt it always ? > >> adding the symbol into the libc too, as it is required by an our >> customer on production, but I'd like to have a common fix also for the >> trunk. > > looks like we'll need to relocate it to libc.a from libdl.a > -mike > Yes, I don't want to keep it into libdl.a and libc.a, only ld.so and libc.a. Anyway the dl_iterate_phdr implementation needs to handle the statically linked application too, as glibc actually does. I'll provide a patch for review soon. Further, basing on Bernds suggestion, I'm building gcc with a patch to use generic unwind-dw2 implementation. Anyway we are discussing what is the best solution for us. Thanks, 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