From owner-svn-ports-head@FreeBSD.ORG Mon Jul 21 13:53:48 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 5FB08BE8; Mon, 21 Jul 2014 13:53:48 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30D622872; Mon, 21 Jul 2014 13:53:47 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id d1so4187326wiv.1 for ; Mon, 21 Jul 2014 06:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=HD3cDiF2T5qSbl0PVUm5inPjVs3tLFH5oya+y10c2/E=; b=zjfbf5jwzb7y7QFYWzztcpZfnC61+1SIiWmUFCI9b7O0OkSNEq7HRcj2uOo7DFejAU 3e7fV9VN37GidIP+b4gvPwhtjMwp3j0e4TdAE11/X4y7YulKc2YT3/Chm5ewuplE/3g+ IIIYQuYUoPaQIwmP7izWbAxoje3d1xOLq4nsTZvmFGn7IxDCeAXDfM9kRdRFJ6JxxHBw iXU2KVYS5kqEvYumXXKGzCFBG5JLy6QsBY4nfLCZBo5FsGxeRTwYddY7amPdAGGY2ghq C3IJ2XDagIKIE30h9rWjXSnJIJBUPATlgmovCl/YAAJ60Gwjvb/Pt5QcrU3SJziupcWr OtEw== X-Received: by 10.180.12.33 with SMTP id v1mr4840882wib.0.1405950825363; Mon, 21 Jul 2014 06:53:45 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n2sm37799866wjf.40.2014.07.21.06.53.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Jul 2014 06:53:44 -0700 (PDT) Sender: Baptiste Daroussin Date: Mon, 21 Jul 2014 15:53:42 +0200 From: Baptiste Daroussin To: Tijl Coosemans Subject: Re: svn commit: r362304 - head/x11-toolkits/pango Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f+W+jCU1fRNres8c" Content-Disposition: inline In-Reply-To: <20140721153657.17c64594@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: svn-ports-head@freebsd.org, kwm@FreeBSD.org, svn-ports-all@freebsd.org, marino@freebsd.org, John Marino , 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: Mon, 21 Jul 2014 13:53:48 -0000 --f+W+jCU1fRNres8c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 :) so if one uses binutils from ports instead of binutils from base one of the= demo (text_demo2.c) will fail to link (text_demo2.c explicitly uses a libm funct= ion) while with base binutils (ld) it will build without problems meaning that somehow we are still leaking implicit dependencies. So the thing is we do not yet see problems found by dports because our link= er still leaks implicit libraries... :( Still adding explicit linking to all .pc files is not the right solution. Bapt --f+W+jCU1fRNres8c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPNG2YACgkQ8kTtMUmk6ExAwgCgsBSPcNuLpUL8zQN5PKLwZZ0c a/wAn2Vf2h/EdHSKF4qD8GeJZ76YfjKT =F9X7 -----END PGP SIGNATURE----- --f+W+jCU1fRNres8c--