Re: the meaning of pkgconfig's Libs fields
Robbie Harwood wrote:
k5crypto and com_err are internal libraries used across the
different
interfaces krb5 provides - they're not intended for external
consumption, and upstream doesn't support their direct use by other
applications.
Then they belong in Libs.private, not Libs.
So you're technically right that this information is already
duplicated
by the dependencies libkrb5.so has already, but that's only true on
Linux. The .pc files are provided by upstream, and need to work on all
OSs that upstream supports - which includes OSs whose linkers don't
follow dependencies, like AIX.
The GNU/Linux GNU ld also does not "follow dependencies" unless you use
-Wl,--copy-dt-needed. (This has been the case since Fedora 13, see:
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking .) But
the thing is, for shared libraries, you do not actually want or need the
linker to "follow dependencies". You need to link a library only if you use
it directly. If it is only used through a shared library, then it is enough
that that shared library links it. This should be the case on any sane
operating system.
The issue comes with static linking, because static libraries are not linked
against anything, they are just an archive of object files. So there, you
need to link not only the static library, but also its dependencies. But
that is what Libs.private is supposed to be for.
If the object is going to get loaded at run-time in all cases anyway
(as
is the case here), the cost of this is tiny. The linker will only load
the one copy, and the size difference from having vs. not having the
dependency marked is tiny. Unless this is breaking something, I don't
believe it's worth the effort to change (but I don't represent krb5 and
don't speak for those folks).
Well, this is not an issue if the libraries all come from the same package,
but in general, extra Libs does make a practical difference because it means
your -devel package now has to drag in the -devel packages for all the
libraries in Libs, not just the runtime packages. Otherwise, linking to
those libraries will fail.
For the runtime cost, it could be fixed by using the -Wl,--as-needed flag.
Some distributions use that flag by default, there was also at least one
attempt to get it added in Fedora, but it has not been implemented so far.
But it would really be helpful if the package would not add unnecessary -l
flags to begin with.
Kevin Kofler