dl_iterate_phdr missing in libc

Carl SHAW carl.shaw at st.com
Mon Jan 14 10:12:40 UTC 2008

Hash: SHA1

Carmelo Amoroso wrote:
> 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.

I think the reason is that traditionally embedded boxes only contained a
single monolithic application (and in the past not even an OS).  i.e.
there are no root file system utilities like "ls", etc. and the
application replaces the init process.  This was to reduce system
complexity and keep the software as small as possible (FLASH memory is
relatively expensive).

Except for really basic systems, even embedded boxes these days are
becoming too complicated for such a model so this approach is dying out...

Besides, I think that the performance difference between dynamic and
static on SH4 will be tiny given its 16 bit instruction set (load/stores
via addresses in registers, branch instructions are all relative, etc.)
- - only the dynamic loader would cause a small overhead on startup and
for a simple application this is not worth the problems!


Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the uClibc mailing list