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

Tijl Coosemans tijl at FreeBSD.org
Mon Jul 21 11:27:50 UTC 2014


On Mon, 21 Jul 2014 12:55:23 +0200 John Marino wrote:
> On 7/21/2014 12:12, Tijl Coosemans wrote:
>> On Mon, 21 Jul 2014 07:58:18 +0200 John Marino wrote:
>>> On 7/21/2014 01:33, Tijl Coosemans wrote:
>>>>> The is not the only port that sets the explicit-depends configure option
>>>>> either.
>>>>
>>>> Yes I know.  It must all be removed.  The worst case is the gtk20 port
>>>> which forces everything that uses gtk20 to link with many Xorg libraries
>>>> for no reason.
>>>
>>> For no reason?
>>> Pango contains symbols from each of those libraries.  If you link pango
>>> without linking the xorg library, you're going to get a reference error
>>> if the linker requires explicit linking.
>> 
>> Pango uses Xorg symbols, so pango must link with Xorg libraries.
>> Executable X uses Pango symbols, so X must link with Pango libraries.
>> Executable X does not use Xorg symbols and does not use libm symbols
>> so it should not be forced to link with Xorg libraries and libm just
>> because it links with pango libraries.
>> 
>>> For a linker not requiring explicit linking, it just searches each
>>> shared library listed in the dynamic symbols section until it finds the
>>> symbol it's looking for.
>> 
>> Yes, if executable X did use libm symbols then implicit linking would
>> find libm via the pango libraries.  Explicit linking requires that you
>> add -lm to the linker command line.
>> 
>> FreeBSD 10 and up use explicit linking.
>> 
>>>>> What is the concern here?
>>>>
>>>> The concern is overlinking.  You are forcing everything that uses pango
>>>> to link with libm just to fix a few ports that require libm but forget
>>>> to link with it explicitly.  You are also forcing everything that uses
>>>> pangocairo to link with libfreetype and libfontconfig now.
>>>
>>> It's not the port that requires libm,
>> 
>> Then why are you linking it with libm?
>> 
>>> it's libpango that references
>>> libm.
>> 
>> Correct and therefore libpango must link with libm.  It doesn't mean
>> that everything that links with libpango must also link with libm.
> 
> 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.

>>> As such, it's pango's responsibility to link libm through the pc
>>> file.
>> 
>> No, the .pc file is what other ports use to figure out how to link
>> with libpango, through the output of "pkgconf --libs pango".  You
>> have now added -lm to that output forcing all ports that use libpango
>> to link with libm even if they don't contain any libm symbols.
> 
> As we don't have granularity down to function level, the pc files has to
> assume the port might reference a function that references a libm
> symbol.  It's certainly wrong to assume it won't.
> 
> If the port contained a libm symbol then it would need to have -lm
> LDFLAG on it's own and not rely on it to come from an unrelated library
> (in this case pango).  The -lm flag is for pango, not the individual port.

This is why I asked you to point to a port that got fixed by this
commit, so you could prove that they do not contain any libm symbol
but still fail to link without -lm.  You will not be able to find
such a port.  They will all contain libm symbols.


More information about the svn-ports-head mailing list