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.
