Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Jul 2014 15:53:42 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Tijl Coosemans <tijl@FreeBSD.org>
Cc:        svn-ports-head@freebsd.org, kwm@FreeBSD.org, svn-ports-all@freebsd.org, marino@freebsd.org, John Marino <freebsd.contact@marino.st>, ports-committers@freebsd.org
Subject:   Re: svn commit: r362304 - head/x11-toolkits/pango
Message-ID:  <20140721135342.GC26699@ivaldir.etoilebsd.net>
In-Reply-To: <20140721153657.17c64594@kalimero.tijl.coosemans.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <stdio.h>
> 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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140721135342.GC26699>