0.9.29, somethings wrong with linker or threading

Joakim Tjernlund joakim.tjernlund at transmode.se
Sat May 26 16:00:06 UTC 2007


> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Kevin Day
> Sent: den 25 maj 2007 19:49
> To: Jason Curl
> Cc: uclibc at uclibc.org
> Subject: Re: 0.9.29, somethings wrong with linker or threading
> 
> On 5/24/07, Jason Curl <jcurlmail at arcor.de> wrote:
> > Kevin Day wrote:
> > > On 5/19/07, Rob Landley <rob at landley.net> wrote:
> > >> On Saturday 19 May 2007 6:27 pm, Kevin Day wrote:
> > >>> I never noticed the problem myself after having almost an entire
> > >>> system compiled, until a configure script test failed to find a
> > >>> library (libao) that was installed.
> > >> So it's reproducible, then?  (I haven't seen it yet, but 
> I'm not doing much
> > >> with threading.)
> > >>
> > >
> > > Reproducable indeed!  I have finally found the problem.
> > >
> > > First, in order to rule out gcc (at least the specific gcc-4.1
> > > version) I made the effort and got gcc-4.2 working (thus the long
> > > delay).
> > >
> > > Now here is the problem.  The problem only occurs when 
> applications
> > > use '-pthread' instead of directly calling "-lpthread".  
> I know there
> > > is a reason for this, but I cannot remember.  However, 
> after removing
> > > the -pthread from the fuse project the linker is now able 
> to properly
> > > identify that the threaded libraries are missing at link time.
> > >
> > > This means that my test.c program will now generate the 
> correct errors
> > > for when threading is used but not linked to.
> > >
> > > I suspect a solution might be to edit the startfile_specs and add
> > > something like the following "%{-pthread: -lpthread}" in 
> gcc.  Please
> > > correct my syntax if necessary as I am very inexperienced with the
> > > specsfile syntax.
> > >
> > > Although I am not certain why this problem didnt show up 
> in 0.9.28,
> > > but perhaps it did but was not as obvious.
> > >
> > > I am about to start the process of testing this startfile 
> spec test of
> > > having -pthread replaced with -lpthread when called. Please let me
> > > know if there are more steps needed to do this correctly.
> >
> > Kevin, where do I find this? I had a SEGV for x86 when using
> > uClibc0.9.29 with binutils 2.17, kernel 2.6.20.4 as the headers, GCC
> > 4.1.2. It only occurred for programs that were linked using 
> pthreads as
> > well and it would crash before entering main(). I didn't 
> have a debug
> > environment for the target.
> >
> > I worked around the problem after I found I'm using the 
> newer versions
> > of threading in 'make uclibc-menuconfig'. I changed it to 
> use the old
> > version (more stable) and it worked again.
> >
> > I'd like to go back and see if I can confirm what you've 
> found as well
> > (but first I'm not 100% sure if it's the same problem).
> >
> > Jason.
> > _______________________________________________
> > uClibc mailing list
> > uClibc at uclibc.org
> > http://busybox.net/cgi-bin/mailman/listinfo/uclibc
> >
> 
> At this point i am now using gcc-4.2.0 uClibc-0.9.29+linuxthreads.old
> binutils-2.17 linux-2.6.21.2 headers
> 
> The two existing applications that have this problem are perl-5.8.8
> and fuse-2.6.5.
> 
> Any application that tries to link to -lperl will fail, even though
> perl's library shows that is has  pthread.so linked and the
> application that links to it will segfault unless it also directly
> calls -pthread or -lpthread, even though the application itself may
> not be using threads.
> 
> So if vim has compiles with perl support, it will segfault on startup,
> without perl support = no segfault.
> 
> Most notable reproductions is compile perl and install once, then
> compil perl again.  Perl will attempt to use the system libperl.so for
> miniperl, because the perl build system fails to understand that it
> needs to pass -pthread, it will fail to compile.
> 
> Also, after looking at the gcc-specsfile, the -pthread to -lpthread is
> present afterall.
> To further debug this, I will probalby create a dummy library that
> links to perl and use the dummy program 'test.c' and link to the dummy
> program.  Hopefully this makes things easier to identify AND debug.
> 
> I also wonder if it is possible for -now to be causing problems like
> this? I am not very familiar with the details of -now.

Maybe, NOW will reloc all function at startup. LAZY will do it
when the function is called for the first time.

> 
> I also MAY try to build against the newer more unstable threads to see
> if any behavior changes in regards to the problem.




More information about the uClibc mailing list