[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Static libraries in development packages

On Sat, Apr 16, 2011 at 09:55:34AM +0200, Goswin von Brederlow wrote:
> "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.

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.


[1] http://www.rrplanet.com/reproducible-research-librum/

Attachment: signature.asc
Description: Digital signature

Reply to: