This is the mail archive of the
mailing list for the libstdc++ project.
Re: USER: linuxthreads causes segfault
- To: libstdc++ at sourceware dot cygnus dot com
- Subject: Re: USER: linuxthreads causes segfault
- From: Stephen Webb <stephen dot webb at bregmasoft dot com>
- Date: Wed, 20 Dec 2000 09:24:53 -0500
- Organization: CyberSafe
- References: <20001220085233.A3935@kungfu.ixla.com.au>
On Tue, 19 Dec 2000, Richard Andrews wrote:
> > Exactly how did you configure gcc when you built it? If done as a
> > separate step, exactly how did you configure libstdc++-v3 when you
> > built it?
> gcc and libstdc++ were built at the same time as follows
> With libstdc++-2.90.8 installed in libstdc++ under gcc-2.95.2 (version 2 libstdc++ and libio removed as per instructions in HTML doc)
> gcc-2.95.2/configure i686-pc-linux-gnu --prefix=/usr --enable-namespaces --enable-threads=posix
> Every exe crashes on exit like this when linked against libpthread.
> However, for trivial exes which don't actually use any symbols from libpthread, I can make them run OK by explicitly linking ld-linux.so BEFORE libpthread.
> Makes me think that there is some symbol conflict among libstdc++, ld-linux and pthreads.
> As pthreads and ld-linux exist quite happily in a C context I have to assume that the symbol is something in libstdc++.
I have been experiencing the same phenomenon using CVS builds. I'm trying to come up with a simple test case since
it only seems to happen with complex third-party programs (ie. attempted rebuilds of the Qt libraries and KDE --
okay, so I get my kicks through self-flagellation), but have been thus far unsuccessful. I do believe the problem
lies in some interaction bewteen the destructors of the global IOStreams (cout, cerr, and so forth) and something in
the glibc2 runtime, but at this point I'm in over my head.
Perhaps this hint might point someone more intimate with the code base in the right direction. Meantime I'll be
working on finding a simple test case.
Stephen M. Webb