From owner-freebsd-hackers Thu Feb 7 23:51:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.viasoft.com.cn (unknown [61.153.1.177]) by hub.freebsd.org (Postfix) with ESMTP id 59C4D37B400; Thu, 7 Feb 2002 23:51:38 -0800 (PST) Received: from viasoft.com.cn (davidwnt.viasoft.com.cn [192.168.1.239]) by mail.viasoft.com.cn (8.9.3/8.9.3) with ESMTP id QAA18037; Fri, 8 Feb 2002 16:00:50 +0800 Message-ID: <3C63840D.3060408@viasoft.com.cn> Date: Fri, 08 Feb 2002 15:53:49 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jason Evans Cc: Maxim Sobolev , 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 References: <1013147180.73417.2.camel@notebook> <20020207234233.D23162@canonware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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