On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote: > "Steve M. Robbins" <st...@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.
I see that we read the original comment differently. I was reacting
to the claim "libraries can't be LINKED TO statically". You read it
as "libraries can't be BUILT statically".
With your reading, I agree that it's not *always* possible. At the
end of my remarks, I agreed with the statement
A development package should provide a static library
*if possible*.
> >> 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.
Possibly that's true for many libraries, but surely not all of them.
> 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.
Our priorities are our users.
There are many things that complicate life for a packager, but are
important to do because they benefit our users.
> >> 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.
I don't accept either of your premises.
For my part, I haven't surveyed our users to understand how important
static linking is. However, I do know of communities that routinely
build static binaries in order to guarantee reproducibility of data
analysis results over time -- part of the so-called Reducible Research
movement [1].
Secondly, in my packaging of libraries -- including the monstrous
Boost -- I supply static libs whereever possible, not "as needed".
This is how I've always read the current policy and I believe that
phrase best reflects current practice.
Regards,
-Steve
[1] http://www.rrplanet.com/reproducible-research-librum/
signature.asc
Description: Digital signature
