x86 cross toolchain and pthread_* weak symbols
Mon Nov 30 22:20:00 GMT 2009
Le lundi 30 novembre 2009 Ã 21:51 +0000, Martin Guy a Ã©crit :
> On 11/30/09, Lionel Landwerlin <email@example.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?
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
Finally I found these weak symbols all over the toolchain.
The stack was something like that :
(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.
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc