From owner-svn-ports-all@FreeBSD.ORG Sun Jul 20 23:33:52 2014 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C9447E9; Sun, 20 Jul 2014 23:33:52 +0000 (UTC) Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be [195.238.6.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6656C2961; Sun, 20 Jul 2014 23:33:51 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIMAHdRzFNbs4jr/2dsb2JhbABZgw5SWMUuh0QBgQcXdoQDAQEEATocIwULCw4GBAklDyoeBohNDAEIv1gXj0sHhEYBBI5DjGGBTpJig0Y7 Received: from 235.136-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.136.235]) by relay.skynet.be with ESMTP; 21 Jul 2014 01:33:43 +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 s6KNXgiD006302; Mon, 21 Jul 2014 01:33:42 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Mon, 21 Jul 2014 01:33:42 +0200 From: Tijl Coosemans To: John Marino Subject: Re: svn commit: r362304 - head/x11-toolkits/pango Message-ID: <20140721013342.6c17ecdc@kalimero.tijl.coosemans.org> In-Reply-To: <53CBF2D7.4070005@marino.st> References: <201407200815.s6K8FG8b003096@svn.freebsd.org> <20140720132259.156d687e@kalimero.tijl.coosemans.org> <53CBA770.2010409@marino.st> <20140720113124.GD26778@ivaldir.etoilebsd.net> <20140720165256.1f4d5d07@kalimero.tijl.coosemans.org> <53CBF2D7.4070005@marino.st> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: svn-ports-head@freebsd.org, kwm@FreeBSD.org, Baptiste Daroussin , svn-ports-all@freebsd.org, marino@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:33:52 -0000 On Sun, 20 Jul 2014 18:48:23 +0200 John Marino wrote: > On 7/20/2014 16:52, Tijl Coosemans wrote: >> On Sun, 20 Jul 2014 13:31:24 +0200 Baptiste Daroussin wrote: >>> On Sun, Jul 20, 2014 at 01:26:40PM +0200, John Marino wrote: >>>> On 7/20/2014 13:22, Tijl Coosemans wrote: >>>>> On Sun, 20 Jul 2014 08:15:16 +0000 (UTC) John Marino wrote: >>>>>> Author: marino >>>>>> Date: Sun Jul 20 08:15:16 2014 >>>>>> New Revision: 362304 >>>>>> URL: http://svnweb.freebsd.org/changeset/ports/362304 >>>>>> QAT: https://qat.redports.org/buildarchive/r362304/ >>>>>> >>>>>> Log: >>>>>> x11-toolkits/pango: require explicit linking >>>>>> >>>>>> This new configure argument will list all required libraries in the >>>>>> generated pkgconf files. Before any library indirectly pulled in, such >>>>>> as libm, was not listed. >>>>>> >>>>>> This fixes numerous regression in dports and it's more correct anyway. >>>>> >>>>> No, this is wrong. Each port should link to the libraries it needs on >>>>> its own. No port should rely on other ports to pull in libraries for >>>>> them. >>>> >>>> Then I guess we really don't need pkgconfig .pc files at all then? >>>> (This is the point of .pc files, it tells how to link. libm is directly >>>> used by pango) >>>> >>>> so no, it is not wrong. The generated pc file was wrong, now it's not. >>>> This is why the configuration argument exists. >> >> A .pc file normally has 1 library in the Libs field (the library the .pc >> file is created for) and 0 items in the Requires field. Dependencies go >> in the Libs.private or Requires.private fields. The only reason to add >> dependencies to Libs or Requires is if the headers of the library expose >> the API of those dependencies (e.g. the library headers define macros or >> inline functions that expand to calls to functions in a dependency (such >> as Gtk macros that expand to Glib function calls)). >> >> The pango headers don't even include math.h or complex.h so they cannot >> expose its API. The generated .pc file was correct, now it is wrong. >> >> The reason the configure argument exists is probably because this is an >> old .pc file from before the .private fields existed. > > Again, linking libpango without -libm is an error when explicit linking > is required (as has been the default on binutils for the last 3 > versions). The previous pc did not consider -lm, so it's wrong. No and no. > The proof is in the pudding. When enabling the explicit linking > configure option, it fixed all the explict linking errors seen by ports > depending on pango. Show me such a port. > The is not the only port that sets the explicit-depends configure option > either. Yes I know. It must all be removed. The worst case is the gtk20 port which forces everything that uses gtk20 to link with many Xorg libraries for no reason. > What is the concern here? The concern is overlinking. You are forcing everything that uses pango to link with libm just to fix a few ports that require libm but forget to link with it explicitly. You are also forcing everything that uses pangocairo to link with libfreetype and libfontconfig now.