> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Day > Sent: den 25 maj 2007 19:49 > To: Jason Curl > Cc: [email protected] > Subject: Re: 0.9.29, somethings wrong with linker or threading > > On 5/24/07, Jason Curl <[EMAIL PROTECTED]> wrote: > > Kevin Day wrote: > > > On 5/19/07, Rob Landley <[EMAIL PROTECTED]> 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 > > [email protected] > > 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. _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
