From owner-freebsd-threads@FreeBSD.ORG Mon Sep 8 21:47:36 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C965A16A4BF; Mon, 8 Sep 2003 21:47:36 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0763C43FF3; Mon, 8 Sep 2003 21:47:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h894lZtp019989; Tue, 9 Sep 2003 00:47:35 -0400 (EDT) Date: Tue, 9 Sep 2003 00:47:35 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: rittle@labs.mot.com In-Reply-To: <200309090045.h890jDHT041330@latour.rsch.comm.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: jb@FreeBSD.org cc: freebsd-threads@FreeBSD.org Subject: Re: Removing -pthread from gcc X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@FreeBSD.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2003 04:47:36 -0000 On Mon, 8 Sep 2003, Loren James Rittle wrote: > In article <20030906000902.GA25237@freebsd1.cimlogic.com.au>, > John Birrell writes: > > > If -pthread is intended as a standard FSF gcc option, then it should be mapped > > to a NOOP for FreeBSD IMO. > [...] > > So a NOOP is best. Change gcc in the FSF sources when appropriate, but let > > -current have the change now. > > Ah, I could fully support this esp. if it allowed us to build shared > libraries in ports on FreeBSD which defer selection of the thread > library until run-time link and/or the final application link. I know > this works fine with one-off tweaking of a shared library's code base. > I don't know if it is possible to do without per-library code changes. I can't comment on this. > In the alternative (if cleaner from ELF perspective), could we make > plain -pthread always link weak against the prototype API for POSIX > threads. Then people just pre-load (aka set LD_PRELOAD , see rtld(1)) > the thread library they actually want for the run-time link. People > could also add -lkse, etc to early bind a concrete implementation of > the thread library or for static link situations. Could you explain this (small example)? I'm not sure what you mean by weak (references or definitions?). We already have some pthread_foo() as weak definitions in libc (see libc/gen/_pthread_stubs.c). IIRC, a weak alias (macro __weak_reference) is actually a weak definition, and a true weak reference (#pragma weak pthread_foo) is not the same. > Thank you guys for rethinking a bit. As a side bonus, this would be a > nice win over having to (re-)build the entire ports in lock-step just > to test for best performing thread library. We don't need to do that anyways; see libmap.conf(5). -- Dan Eischen