Re: Static libraries in development packages
"Steve M. Robbins" <steve@sumost.ca> writes:
>> As I've come to understanding, nowadays many libraries doesn't allow
>> trivial static linkage,
>
> I don't follow; it's generally as simple as using -static on
> the link line. Pretty trivial.
Which a) might not be simple to get the build system to do and b) is far
from enough to build a static library.
The problem here is having all the library packages ship the libfoo.a
files in their libfoo-dev packages. Not compiling a static binary once
you have those.
>> and that it's generally not recommended to
>> link statically in packages.
>
> That is completely separate from the question of whether Debian should
> provide static libraries for users to link with. I don't see that it
> should have any bearing.
I think the better question is wether static linking even works at
all?
There are many libraries that use plugins, most importantly libc6. The
probability that you invoke one of the plugin functions in libc6 in any
non trivial programm is high and then the static binary crashes and
burns if the dynamic libc6 on the system is incompatible. And if the
dynamic libc6 on the system is compatible then why would you ever want
to link it static?
Static linking of libc6 basically never makes sense. The same can be
said for many other libs.
On the other hand, even assuming the build system supports a static lib,
building a static lib means building the library twice. That complicates
the rules file and packaging. It also increases package size.
>> Thus I think we should consider updating the policy to either
>> specify that a development package should provide a static library
>> if possible,
>
> I agree with this sentiment.
>
>
> -Steve
Given the cost that involves and that nobody has screamed about it in
the last 10 years I would opt for rephrasing it to "as needed". The
would reflect the current practice best.
MfG
Goswin
Reply to: