From owner-freebsd-ports Mon Jan 22 20:36:15 2001 Delivered-To: freebsd-ports@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2336637B402; Mon, 22 Jan 2001 20:35:57 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA29532; Mon, 22 Jan 2001 23:35:29 -0500 (EST) Date: Mon, 22 Jan 2001 23:35:28 -0500 (EST) From: Daniel Eischen To: Jeremy Lea Cc: ports@FreeBSD.ORG Subject: Re: HEADS UP: -pthread is going to break under -current soon In-Reply-To: <20010122200425.A63549@shale.csir.co.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Jan 2001, Jeremy Lea wrote: > Hi, > > On Mon, Jan 22, 2001 at 04:18:17PM -0500, Daniel Eischen wrote: > > In a couple of days, I'll be committing changes to libc and libc_r > > to allow them to be linked together via -lc_r. libc_r will only > > contain the thread functions and will not contain any libc functions > > as it does currently. We currently use -pthread as a non-standard > > hack to link to libc_r and to prevent linking to libc. After I > > commit these changes, using -pthread will not work; it will produce > > an executable that is only linked to libc_r but which also needs to > > be linked to libc. This also means that all (shared) threaded apps > > will need to be recompiled under -current. > > I would like to object to this change. Using -pthread to link threaded > applications has been well advertised as a FreeBSD way of doing things, > and you are going to break lots of ports, many of which will be non > trivial to fix to work on both -current and -stable. > > What is wrong with leaving '-pthread' as an alias for '-lc_r'? -pthread is integrated into the baseline gcc source. This is out of my control; obrien owns this. -pthread needs to go away at some point, so we'll have to deal with the issue sooner or later. > Also, with regards to the naming of the new library. Even if we get a > new KSE based thread library, we should only ever have one library to > which applications should be linked if they want threads. If they get > userland or kernel threading, or a combination of the two, is irrelevant > (or should be from the point of view of third party applications). I > would therefore suggest that we move now to using libpthread. libc_r and libpthread(KSE) may not be compatible with each other. One will be a many threads to one process, the other many to many (in effect). We need to have both in the tree at the same time for a while. libpthread isn't going to appear one day and just work; it'll probably be much like SMPng. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message