R: Re: Problem with dynamically linked executable on ARM

fabrizio gennari fabrizio.ge at tiscali.it
Wed Dec 16 13:04:18 UTC 2009


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: jpihl at nevion.com
Data: 
16/12/2009 13.39
A: "fabrizio gennari"<fabrizio.ge at tiscali.it>, 
"uclibc at uclibc.org"<uclibc at uclibc.org>
Ogg: Re: Problem with 
dynamically linked executable on ARM

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

-----------------------------------








More information about the uClibc mailing list