From owner-svn-ports-head@FreeBSD.ORG Sun Jul 20 22:12:45 2014 Return-Path: Delivered-To: svn-ports-head@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 BD530D46; Sun, 20 Jul 2014 22:12:45 +0000 (UTC) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DED872208; Sun, 20 Jul 2014 22:12:44 +0000 (UTC) Received: from [192.168.0.22] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 5175E43B9B; Sun, 20 Jul 2014 17:12:25 -0500 (CDT) Message-ID: <53CC3EB8.6070802@marino.st> Date: Mon, 21 Jul 2014 00:12:08 +0200 From: John Marino Reply-To: marino@freebsd.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Baptiste Daroussin , marino@freebsd.org Subject: Re: svn commit: r362304 - head/x11-toolkits/pango 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> <20140720220612.GH26778@ivaldir.etoilebsd.net> In-Reply-To: <20140720220612.GH26778@ivaldir.etoilebsd.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-ports-head@freebsd.org, kwm@FreeBSD.org, Tijl Coosemans , svn-ports-all@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.18 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, 20 Jul 2014 22:12:45 -0000 On 7/21/2014 00:06, Baptiste Daroussin wrote: > On Sun, Jul 20, 2014 at 06:48:23PM +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. >> >> 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. >> >> The is not the only port that sets the explicit-depends configure option >> either. >> >> What is the concern here? Linkers that don't require explicitly >> specified libraries still link with those libraries through recursive >> searching. The end result is the same, so I'm not understanding the >> motivation for this discussion, especially since gnome@ (the maintainer) >> approved the change. >> >> John >> > Checking on some linux they seems to not have the problem with -lm are you sure > that there is no problem with binutils on dragonfly? because checking at pango > headers I cannot see why it would leaking things from libm. > Don't bother with headers. > readelf -d /usr/local/lib/libpango-1.0.so libm is listed as a required shared library, plain as day. for non-explicit linking the linker will pick all those up. For explicit linking, they have to be passed to the linker. John P.S. The real question is why the FreeBSD linker is exempting libm and libz, but not the others...