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

[Baptiste Daroussin]

On Mon, Jul 21, 2014 at 12:12:08AM +0200, John Marino wrote:
> On 7/21/2014 00:06, Baptiste Daroussin wrote:
> > On Sun, Jul 20, 2014 at 06:48:23PM +0200, John Marino wrote:
> >>
> >>
> >> On 7/20/2014 16:52, Tijl Coosemans wrote:
> >>> On Sun, 20 Jul 2014 13:31:24 +0200 Baptiste Daroussin wrote:
> >>>> On Sun, Jul 20, 2014 at 01:26:40PM +0200, John Marino wrote:
> >>>>> On 7/20/2014 13:22, Tijl Coosemans wrote:
> >>>>>> On Sun, 20 Jul 2014 08:15:16 +0000 (UTC) John Marino wrote:
> >>>>>>> Author: marino
> >>>>>>> Date: Sun Jul 20 08:15:16 2014
> >>>>>>> New Revision: 362304
> >>>>>>> URL: http://svnweb.freebsd.org/changeset/ports/362304
> >>>>>>> QAT: https://qat.redports.org/buildarchive/r362304/
> >>>>>>>
> >>>>>>> Log:
> >>>>>>>   x11-toolkits/pango: require explicit linking
> >>>>>>>   
> >>>>>>>   This new configure argument will list all required libraries in the
> >>>>>>>   generated pkgconf files.  Before any library indirectly pulled in, such
> >>>>>>>   as libm, was not listed.
> >>>>>>>   
> >>>>>>>   This fixes numerous regression in dports and it's more correct anyway.
> >>>>>>
> >>>>>> No, this is wrong.  Each port should link to the libraries it needs on
> >>>>>> its own.  No port should rely on other ports to pull in libraries for
> >>>>>> them.
> >>>>>
> >>>>> Then I guess we really don't need pkgconfig .pc files at all then?
> >>>>> (This is the point of .pc files, it tells how to link.  libm is directly
> >>>>> used by pango)
> >>>>>
> >>>>> so no, it is not wrong.  The generated pc file was wrong, now it's not.
> >>>>> This is why the configuration argument exists.
> >>>
> >>> A .pc file normally has 1 library in the Libs field (the library the .pc
> >>> file is created for) and 0 items in the Requires field.  Dependencies go
> >>> in the Libs.private or Requires.private fields.  The only reason to add
> >>> dependencies to Libs or Requires is if the headers of the library expose
> >>> the API of those dependencies (e.g. the library headers define macros or
> >>> inline functions that expand to calls to functions in a dependency (such
> >>> as Gtk macros that expand to Glib function calls)).
> >>>
> >>> The pango headers don't even include math.h or complex.h so they cannot
> >>> expose its API.  The generated .pc file was correct, now it is wrong.
> >>>
> >>> The reason the configure argument exists is probably because this is an
> >>> old .pc file from before the .private fields existed.
> >>
> >> Again, linking libpango without -libm is an error when explicit linking
> >> is required (as has been the default on binutils for the last 3
> >> versions).  The previous pc did not consider -lm, so it's wrong.
> >>
> >> The proof is in the pudding.  When enabling the explicit linking
> >> configure option, it fixed all the explict linking errors seen by ports
> >> depending on pango.
> >>
> >> The is not the only port that sets the explicit-depends configure option
> >> either.
> >>
> >> What is the concern here?  Linkers that don't require explicitly
> >> specified libraries still link with those libraries through recursive
> >> searching.  The end result is the same, so I'm not understanding the
> >> motivation for this discussion, especially since gnome@ (the maintainer)
> >> approved the change.
> >>
> >> John
> >>
> > Checking on some linux they seems to not have the problem with -lm are you sure
> > that there is no problem with binutils on dragonfly? because checking at pango
> > headers I cannot see why it would leaking things from libm.
> > 
> 
> Don't bother with headers.
> 
> > readelf -d /usr/local/lib/libpango-1.0.so
> 
> libm is listed as a required shared library, plain as day.
> for non-explicit linking the linker will pick all those up.  For
> explicit linking, they have to be passed to the linker.

Anything linking to libpango will not have to link with libm because of that,
that just mean that libpango itself needs to load the libm.so when being loaded

final binary linking to libpango only needs explicit link to libm only if pango
headers make the binary to use directly libm symbols which is not the case here.

regards,
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-head/attachments/20140721/b16de022/attachment.sig>