From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 10:06:40 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59A9016A4B3; Wed, 24 Sep 2003 10:06:40 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C84E4400F; Wed, 24 Sep 2003 10:06:39 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h8OH6YID071581; Wed, 24 Sep 2003 12:06:34 -0500 (CDT) (envelope-from dan) Date: Wed, 24 Sep 2003 12:06:34 -0500 From: Dan Nelson To: deischen@freebsd.org Message-ID: <20030924170633.GA30073@dan.emsphone.com> References: <3F71396A.6070508@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: Doug Barton cc: Freebsd Current Subject: Re: Fixing -pthreads (Re: ports and -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2003 17:06:40 -0000 In the last episode (Sep 24), Daniel Eischen said: > On Wed, 24 Sep 2003, Scott Long wrote: > > Daniel Eischen wrote: > > > o Doesn't break applications that use both -pthread and > > > -l. We've been able to link both libc_r and libc > > > in -current for well over 2 years. Indeed, if you build KDE > > > and X with libpthread installed, you will see binaries that > > > are linked to both libc_r and libpthread. > > > > I can't see how this behaviour would not be considered a bug, if it > > is indeed true. Are you saying that there are packages out there > > that will detect both -lpthread and -pthread and attempt to use > > both on the compilers and linker lines? > > Yes, it's not just that. They can also find libc_r and include that > (-lc_r) with -pthread. I installed libkse as libpthread and made the > appropriate links and built X and KDE and there were a lot of > binaries that were linked to both libc_r and libpthread. Does it really matter if you end up linked to multiple threads libraries? The first library providing a symbol wins, so the other shlibs just won't get used at all. Libraries linked from the executable trump libraries linked from libraries, and LD_PRELOAD wins above all. If one threads library exports a symbol not in the others, I'd call that an API bug in the first library. This should be no different from explicitly linking in dmalloc to override the malloc functions in libc, for example. -- Dan Nelson dnelson@allantgroup.com