From owner-svn-ports-head@FreeBSD.ORG Sun Sep 14 09:28:49 2014 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B2AE34E; Sun, 14 Sep 2014 09:28:49 +0000 (UTC) Received: from mailrelay005.isp.belgacom.be (mailrelay005.isp.belgacom.be [195.238.6.171]) by mx1.freebsd.org (Postfix) with ESMTP id 464DCC86; Sun, 14 Sep 2014 09:28:47 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8GAFleFVRR8a8O/2dsb2JhbABggw1TTQrJSodMAYEDF3iEBAEBBDocIxALFAQJJQ8qHgYTiEIBCLciARePGjMHhEsBBJYEhwOBYJNgg2A7LwEBgkgBAQE Received: from 14.175-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.175.14]) by relay.skynet.be with ESMTP; 14 Sep 2014 11:28:40 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.9/8.14.9) with ESMTP id s8E9ScsQ001097; Sun, 14 Sep 2014 11:28:38 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Sun, 14 Sep 2014 11:28:37 +0200 From: Tijl Coosemans To: "Jason E. Hale" Subject: Re: svn commit: r368130 - in head/devel/bennugd-core: . files Message-ID: <20140914112837.375964ab@kalimero.tijl.coosemans.org> In-Reply-To: References: <201409131920.s8DJKNGP095467@svn.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "svn-ports-head@freebsd.org" , "svn-ports-all@freebsd.org" , ports-committers X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 09:28:49 -0000 On Sun, 14 Sep 2014 04:20:34 -0400 "Jason E. Hale" wrote: > On Sat, Sep 13, 2014 at 3:20 PM, Tijl Coosemans wrote: >> Author: tijl >> Date: Sat Sep 13 19:20:22 2014 >> New Revision: 368130 >> URL: http://svnweb.freebsd.org/changeset/ports/368130 >> QAT: https://qat.redports.org/buildarchive/r368130/ >> >> Log: >> - Convert to USES=libtool >> - Remove -lpthread patching >> >> Modified: head/devel/bennugd-core/files/patch-configure >> ============================================================================== >> --- head/devel/bennugd-core/files/patch-configure Sat Sep 13 19:03:41 2014 (r368129) >> +++ head/devel/bennugd-core/files/patch-configure Sat Sep 13 19:20:22 2014 (r368130) >> @@ -1,6 +1,6 @@ >> --- configure.orig 2013-01-06 05:50:56.000000000 +0400 >> +++ configure 2013-09-12 05:48:18.186226351 +0400 >> -@@ -11277,10 +11277,10 @@ >> +@@ -11277,7 +11277,7 @@ >> USE_OPENSSL=no >> ;; >> >> @@ -8,8 +8,4 @@ >> + dragonfly* | freebsd*) >> INCLUDES="-I/usr/local/include" >> COMMON_CFLAGS="-Wall -DTARGET_BSD -DUSE_OPENSSL" >> -- COMMON_LDFLAGS="-L/usr/local/lib -lpthread" >> -+ COMMON_LDFLAGS="-L/usr/local/lib -pthread" >> - LIBSSL="crypto" >> - USE_OPENSSL=yes >> - ;; >> + COMMON_LDFLAGS="-L/usr/local/lib -lpthread" >> > > Should we no longer be patching for -lpthread? Does > https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-pthread.html > no longer apply? If you ask me it doesn't. The C compiler automatically links in libc and we used to have two, libc (without threading) and libc_r (with threading). The -pthread flag told the compiler which one to use. Nowadays we have one libc and libpthread provides threading functions. All -pthread does is tell the compiler to link in libpthread, just like -lpthread does. They are the same. It used to be that this libpthread could only be linked into executables and not into libraries. This meant that if an executable depended on a library that used threading, it had to be linked with libpthread even if it didn't use threading itself. This is why several ports still have LDFLAGS+=-pthread or similar, just because one of the libraries in the dependency chain used threading. This is no longer necessary. There's one thing that is still special about libpthread and that is that it needs to be loaded into memory before libc because it overrides some libc symbols. So if you mention -lc explicitly on the command line (which you normally don't), -lpthread has to appear in front of it. And, if an executable dlopen()s a library that uses threading, the executable needs to be linked with libpthread even if it doesn't use threading itself.