Re: Bug#185868: libpq.a not linked with kerberos libs

[Wichert Akkerman <wichert@wiggy.net>]

Previously Oliver Elphick wrote:
> Why is this a bug?  Surely you need to supply the krb5 static library
> when you are linking your executable in the same way as you have linked
> ssl and crypto.  I should not, as I understand it, dynamically link krb5
> into libpq.a.  If I statically link it, I will be including all of
> libkrb5.a inside libpq.a, which also cannot be right.

How do you expect upstream maintainers to handle static libraries? I can
see three options:

* provide a XXX-config tool that outputs the list of needed compile and
  link options. This is the approach taken by GNOME (and probably
  others) and works well. It means people using a library will
  automatically pick up the needed compile/link flags and will not find
  things suddenly breaking.

* link everything into the static library and trust the linker to
  remove anything that will be duplicated in the final result. This is
  even easier to use than the previous option (no need to call
  XXX-config).

* expect (upstream) maintainer to somehow know which libraries the
  static library on a system needs in order to link for every different
  platform the source is compiled with. Major pain whenever a
  distribution changes something in its libraries since it means all
  released soruces will suddenly break and more tests and rules need
  to be added.

I don't consider the last option to be acceptable since it makes it very
painful for maintainers to make sure their software will always work.

I'm cc'ing this to debian-policy since it might be wise to come up
with a policy on this topic. (note that I'm not subscribed there)

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>           http://www.wiggy.net/
A random hacker