From owner-svn-ports-head@FreeBSD.ORG Wed Jul 23 12:10:50 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 ABA41FCF; Wed, 23 Jul 2014 12:10:50 +0000 (UTC) Received: from mailrelay001.isp.belgacom.be (mailrelay001.isp.belgacom.be [195.238.6.51]) by mx1.freebsd.org (Postfix) with ESMTP id 70CF723EF; Wed, 23 Jul 2014 12:10:49 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGAHClz1Nbs4XT/2dsb2JhbABZgw5STQrHaIdFAYEKF3aEBAEFViMQCw4KCSUPKh4GLogrAQi/RBePSweERgWSQ4hpgVOSboNKOy8B Received: from 211.133-179-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.179.133.211]) by relay.skynet.be with ESMTP; 23 Jul 2014 14:10:41 +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 s6NCAf0T003392; Wed, 23 Jul 2014 14:10:41 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Wed, 23 Jul 2014 14:10:36 +0200 From: Tijl Coosemans To: Baptiste Daroussin Subject: Re: svn commit: r362304 - head/x11-toolkits/pango Message-ID: <20140723141036.27896d0a@kalimero.tijl.coosemans.org> In-Reply-To: <20140721135342.GC26699@ivaldir.etoilebsd.net> References: <53CBF2D7.4070005@marino.st> <20140721013342.6c17ecdc@kalimero.tijl.coosemans.org> <53CCABFA.7090202@marino.st> <20140721121214.1d1f3ef5@kalimero.tijl.coosemans.org> <53CCF19B.3060906@marino.st> <20140721132621.64ef394c@kalimero.tijl.coosemans.org> <53CD047B.7080104@marino.st> <20140721144356.72c4e5c2@kalimero.tijl.coosemans.org> <53CD0F04.4040709@marino.st> <20140721153657.17c64594@kalimero.tijl.coosemans.org> <20140721135342.GC26699@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/06BzVZC1V/OJyJ1Vlq8vpvB"; protocol="application/pgp-signature" Cc: svn-ports-head@freebsd.org, kwm@FreeBSD.org, svn-ports-all@freebsd.org, marino@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: Wed, 23 Jul 2014 12:10:50 -0000 --Sig_/06BzVZC1V/OJyJ1Vlq8vpvB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 21 Jul 2014 15:53:42 +0200 Baptiste Daroussin wrote: > On Mon, Jul 21, 2014 at 03:36:57PM +0200, Tijl Coosemans wrote: >> On Mon, 21 Jul 2014 15:00:52 +0200 John Marino wrote: >>> On 7/21/2014 14:43, Tijl Coosemans wrote: >>>> On Mon, 21 Jul 2014 14:15:55 +0200 John Marino wrote: >>>>> On 7/21/2014 13:26, Tijl Coosemans wrote: >>>>>> On Mon, 21 Jul 2014 12:55:23 +0200 John Marino wrote: >>>>>>> Everything that uses a pango function that has a libm symbol must a= lso >>>>>>> link with libm. >>>>>> >>>>>> This is a completely false statement. If X links to Y and Y uses Z >>>>>> symbols, you do not have to link X with Z. Y links with Z and that = is >>>>>> enough. Otherwise X would have to link with its entire dependency >>>>>> tree. >>>>> >>>>> If the linker doesn't follow Y's link to Z, how is it supposed to >>>>> resolve Z references? >>>>=20 >>>> If X doesn't contain Z references the linker doesn't have to resolve >>>> Z references. >>>>=20 >>>> If X does contain Z references then explicit linking requires that you >>>> explicitly link X with -lZ and that you cannot rely on -lY to imply -l= Z. >>>=20 >>> This seems to be the heart of our disagreement. >>> I am saying X can pull in a function of Y that contains a symbol of Z. >>> In that case, there's no reference of Z in X, but when linking X it >>> still needs -lZ. >>=20 >> Let's work out an example: >>=20 >> -- X.c -- >> void funcY( void ); >> int main( void ) { >> funcY(); >> return( 0 ); >> } >> --------- >>=20 >> -- Y.c -- >> void funcZ( void ); >> void funcY( void ) { >> funcZ(); >> } >> --------- >>=20 >> -- Z.c -- >> #include >> void funcZ( void ) { >> ( void ) puts( "Hello world" ); >> } >> --------- >>=20 >> Create libZ.so: >> % cc -shared -o libZ.so Z.c >>=20 >> Create libY.so linking it with libZ: >> % cc -shared -o libY.so Y.c -Wl,-rpath,. -L. -lZ >>=20 >> Create X linking it with libY, but not libZ: >> % cc -o X X.c -Wl,-rpath,. -L. -lY >>=20 >> Run ./X: >> % ./X >> Hello world >>=20 >>=20 >> Now, what do you get? >=20 > print/libharu is a good example that shows the problem. for which anyway > explicit linking is a wrong idea :) >=20 > so if one uses binutils from ports instead of binutils from base one of t= he demo > (text_demo2.c) will fail to link (text_demo2.c explicitly uses a libm fun= ction) > while with base binutils (ld) it will build without problems meaning that > somehow we are still leaking implicit dependencies. >=20 > So the thing is we do not yet see problems found by dports because our li= nker > still leaks implicit libraries... :( >=20 > Still adding explicit linking to all .pc files is not the right solution. I've submitted a PR to track this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192062 --Sig_/06BzVZC1V/OJyJ1Vlq8vpvB Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREKAAYFAlPPpkEACgkQfoCS2CCgtitQKAD8CeibXlO4Hcf+D/rhB6SrZ9DY Oy+tCUgB7hR53rIi2CoA+QHJR/6rSFJ0UjR8Af2tjjy1clwLzqg7t1I26eqh+LZN =92+x -----END PGP SIGNATURE----- --Sig_/06BzVZC1V/OJyJ1Vlq8vpvB--