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 <[EMAIL PROTECTED]> http://www.wiggy.net/ A random hacker
