R: Re: Problem with dynamically linked executable on ARM

Joachim Pihl jpihl at nevion.com
Wed Dec 16 13:09:08 UTC 2009


On Wed, 16 Dec 2009 14:04:18 +0100, fabrizio gennari  
<fabrizio.ge at tiscali.it> wrote:

> 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.

I know, I was planning to write "cured", but it slipped. I am also running  
ARM (PXA255) and uclibc 0.9.30.1, a 2.6.27.39 kernel, building with a  
Buildroot generated tool chain on Ubuntu 9.10. There may be some file  
corruption happening here.


>
> ----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