Re: x86 cross toolchain and pthread_* weak symbols

[Lionel Landwerlin <llandwerlin at gmail dot com>]

Le lundi 30 novembre 2009 Ã 21:51 +0000, Martin Guy a Ãcrit :
> On 11/30/09, Lionel Landwerlin <llandwerlin@gmail.com> wrote:
> >  I'm using crosstool-ng to generate a cross toolchain for an x86 target
> >  (nothing too exciting...) and I'm kind of disappointed because I get
> >  some pthread_* weak symbols inside my toolchain :
> >
> >  /opt/cross_x86/i686-cm-linux-gnu/lib/libdl-2.10.2.so
> >          w __pthread_getspecific
> >          w __pthread_key_create
> >          w __pthread_once
> >          w __pthread_setspecific
> >
> >  I'm wondering why I don't have these weak symbols on my host system
> >  (debian unstable) which is an x86 too, and using the same toolchain
> >  (both using gcc-4.3.4 + eglibc-2.10/nptl, but binutils 2.19 in my cross
> >  toolchain, 2.20 on my host system).
> 
> Does that cause any disfunction or is it just annoying?
> 
>    M
> 

Well, after I built my toolchain, I started playing a little with
buildroot. I did build a rootfs with it, containing directfb.
Every directfb application I launched used to crash early in the
initialization of directfb. After launching gdb on a directfb example, I
found that the process was crashing with its pc at 0x0. The previous
function in the stack was pthread_once. The address of the pthread_once
symbol in the process was wrong (that's what I though first), it was
inside the mapped code of libdl.so, instead of the mapped code of
libpthread.
Finally I found these weak symbols all over the toolchain.

The stack was something like that :

0x0
pthread_once
dlopen

(I will provide stack trace later)

Directfb examples'/applications' are the only binary crashing as
described. But I didn't build a lot of packages and directfb might be
the only binary using dlopen in my setup.

Regards,

-- 
Lionel Landwerlin


--
For unsubscribe information see http://sourceware.org/lists.html#faq