Date: Fri, 08 Feb 2002 15:53:49 +0800 From: David Xu <davidx@viasoft.com.cn> To: Jason Evans <jasone@canonware.com> Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, 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: <3C63840D.3060408@viasoft.com.cn> References: <1013147180.73417.2.camel@notebook> <20020207234233.D23162@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
sound like cooool, I like the libpthread hook. hahaha. -- David Xu 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. > >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 > 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?3C63840D.3060408>