Hi Joachim. Thank you for the quick reply. Your suggestion is hard to apply in this case, as the command line to compile and link is just
arm-linux-gcc test.c -g -o testarm and the only library the executable links to is libc (which links to ld-uClibc.so.0). What you describe looks more like a workaround than a solution. This is OK because it makes things work, but it should sound as an alarm bell for the library developers. ----Messaggio originale---- Da: [email protected] Data: 16/12/2009 13.39 A: "fabrizio gennari"<[email protected]>, "[email protected]"<[email protected]> Ogg: Re: Problem with dynamically linked executable on ARM On Wed, 16 Dec 2009 13:33:09 +0100, fabrizio gennari <[email protected]> wrote: > Hello. > > I am trying to build an ARM build environment on an Ubuntu > 9.10 > machine. So far I've compiled binutils and gcc for an arm-linux > target, > and cross-compiled uClibc and gdb. > > Then, I wrote a small > hello world application and used the > cross-compiler to compile it with > and without the -static flag. > > I copied the statically compiled binary > on the ARM device, which > has a serial shell console. I ran it and > everything went OK. > Then I copied the dynamically compiled binary on > the device. I also > copied libuClibc- 0.9.30.1.so as /lib/libc.so.0 > (glibc was also there, > but as /lib/libc.so.6) and ld-uClibc-0.9.30.1. > so as > /lib/ld-uClibc.so.0 . > The program segfaults even before getting > to main. > By running gdb on the device, I found out that > __uClibc_main () > calls _init (). _init () returns, and, immediately > afterwards, > __uClibc_main () calls _dl_app_init_array (), which in its > turn > invokes _dl_run_init_array (). > The SIGSEGV happens almost > immediately in _dl_run_init_array (). > By peeking in uClibc's source > code, I got the suspect that the > variable _dl_loaded_modules stays > NULL, instead of being > initialized. That variable is declared in > ldso/ldso/dl-symbols.c . > > When is that variable supposed to be > initialised? And, overall, > how do I get my program to work? I have seen the exact same thing lately, and I cured it by shuffling the order of the libraries at the link command. It will exhibit this behaviour if boost_thread-mt is listed before pthread in the link command in our applications. It did not use to do that. -- Joachim Pihl Senior R&D Engineer Nevion Tel: +47 33 48 94 66 Fax: +47 33 48 99 98 Mobile: +47 91 33 98 91 [email protected] www.nevion.com ----------------------------------- The Global Video Transport Leader ----------------------------------- _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
