On 5/26/07, Joakim Tjernlund <[EMAIL PROTECTED]> wrote: > > -----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. > >
alright, so I spent quite a lot of timing trying to isolate this issue, in the process I've discovered that gcc-4.2.0 is not only stable, but working better than all versions tried. (minus one bug with openssh's ssh-genkey via openssl) It's worth trying for uClibc. Your gcc-4.2.0 snapshot patches all went through with no trouble. Only 1-problem where --target=i686-pc-linux-uclibc seems to cause no gcc shared libraries to be built whatsoever with --enable-shared --disable-static, but --target=i686-pc-linux-gnu does produce gcc shared libraries (such as libgcc_s.so). I have tested my problem with gcc-3.4.6, gcc-4.1.2, gcc-4.2.0 under uClibc-0.9.29, all return same problem. I tried using the linux-libc-headers-2.6.12.0, which also showed no changes. I then tried uClibc-0.9.28.3 in the same situations, the linking problem completely vanishes when using this version. No other changes were done to the built system. I haven't touched binutils-2.17 during this entire time, but I may have to do that on my next pass. FYI: I used linuxthreads.old throughout every build. -- Kevin Day _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
