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

[Tijl Coosemans]

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

I've submitted a PR to track this:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192062
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20140723/0e0a0f12/attachment.sig>