Date: Thu, 7 Feb 2002 23:42:33 -0800 From: Jason Evans <jasone@canonware.com> To: Maxim Sobolev <sobomax@FreeBSD.org> 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: <20020207234233.D23162@canonware.com> In-Reply-To: <1013147180.73417.2.camel@notebook>; from sobomax@FreeBSD.org on Fri, Feb 08, 2002 at 07:46:34AM %2B0200 References: <1013147180.73417.2.camel@notebook>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. Jason 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?20020207234233.D23162>