0.9.29, somethings wrong with linker or threading

Kevin Day thekevinday at gmail.com
Fri May 25 17:49:25 UTC 2007


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.

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



More information about the uClibc mailing list