Date: Fri, 08 Feb 2002 11:29:48 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Jason Evans <jasone@canonware.com> Cc: jdp@FreeBSD.org, deischen@FreeBSD.org, jasone@FreeBSD.org, hackers@FreeBSD.org, jlemon@FreeBSD.org Subject: Re: Linking libc before libc_r into application causes weird problems Message-ID: <3C639A8C.6D100326@FreeBSD.org> References: <1013147180.73417.2.camel@notebook> <20020207234233.D23162@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Evans wrote: > > On Fri, Feb 08, 2002 at 07:46:34AM +0200, Maxim Sobolev wrote: > > Hi, > > > > When working on updating port of Ximian Evolution to the latest released > > version I have stuck to the problem - the new version of application > > just hanged on startup on my 5-CURRENT box. After lot of digging and > > debugging I found that the source of the problem is that the resulting > > application had libc linked in before libc_r, which caused waitpid() in > > the ORBit library just hang forever, even though child process died > > almost instantly (I see zombie in the ps(1) output). When program was > > relinked with -pthread flag, which seemingly forcing "right" order of > > libc/libc_r (libc_r first) the problem disappeared. > > > > Based on the problematic code in the ORBit I had prepared short testcase > > illustrating the problem and attaching it with this message. The problem > > could be exposed by compiling the test.c using the following command: > > > > $ cc test.c -o test -lc -lc_r > > > > When either of -lc or -lc_r is omitted, or their order is reversed the > > problem disappears. The problem doesn't exist on 4-STABLE. > > > > Any ideas, comments and suggestions are welcome. > > IIRC, Dan changed things in -current about six months ago so that -lc_r > would do the right thing. Previously (and still in -stable), -pthread was > necessary in order to prevent libc from being implicitly linked in. > There's some magic in the compiler front end that prevents libc from being > implicitly linked in if libc_r is specified. It may re-order things as > well, but I'd have to look at the code to verify that. In any case, don't > manually specify both, or Bad Things will happen, as you've discovered. I don't (this was just a testcase). In real life it was really unclear where that libc came from, because there were no -lc in the command line and no of the shared libraries specified contained explicit libc dependency (at least according to ldd(1)). > It's my hope that we'll be able to use -lpthread by the 5.0 release, which > is what the standards say should work. We could have that right now, but > we've been holding off, since threads may be KSE-based by the 5.0 release. That would be nice, but we have a real problem at hand. As I said, I think that ld(1) should be smart enough to reorder libc/libc_r so that libc_r is always linked before libc. This is clearly not the case right now. Unfortunately there is no easy way to reproduce this, but if you have some spare CPU cycles try to remore explicit -pthread from ports/mail/evolution/Makefile, build the port on -current and do `ldd /usr/X11R6/bin/evolution'. You will see that libc.so.X precedes libc_r.so.X, even though -lc wasn't supplied to a linker, while -lc_r was. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C639A8C.6D100326>