svn commit: r362304 - head/x11-toolkits/pango

[Baptiste Daroussin]

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 also
> >>>>> 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?
> >> 
> >> If X doesn't contain Z references the linker doesn't have to resolve
> >> Z references.
> >> 
> >> 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 -lZ.
> > 
> > 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.
> 
> Let's work out an example:
> 
> -- X.c --
> void funcY( void );
> int main( void ) {
> 	funcY();
> 	return( 0 );
> }
> ---------
> 
> -- Y.c --
> void funcZ( void );
> void funcY( void ) {
> 	funcZ();
> }
> ---------
> 
> -- Z.c --
> #include <stdio.h>
> void funcZ( void ) {
> 	( void ) puts( "Hello world" );
> }
> ---------
> 
> Create libZ.so:
> % cc -shared -o libZ.so Z.c
> 
> Create libY.so linking it with libZ:
> % cc -shared -o libY.so Y.c -Wl,-rpath,. -L. -lZ
> 
> Create X linking it with libY, but not libZ:
> % cc -o X X.c -Wl,-rpath,. -L. -lY
> 
> Run ./X:
> % ./X
> Hello world
> 
> 
> Now, what do you get?
> 

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 function)
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 linker
still leaks implicit libraries... :(

Still adding explicit linking to all .pc files is not the right solution.

Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20140721/c82eac82/attachment.sig>