Problem with dynamically linked executable on ARM

[Joachim Pihl]

On Wed, 16 Dec 2009 13:33:09 +0100, fabrizio gennari  
<fabrizio.ge at tiscali.it> 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
jpihl at nevion.com
www.nevion.com

-----------------------------------
The Global Video Transport Leader
-----------------------------------