Static libraries in development packages
 

Currently section 8.3 in the policy specifies that "The static library
(libraryname.a) is usually provided in addition to the shared
version", i.e. it doesn't provides any guidelines if a development
package should or shouldn't provide a static library at all. Also it's
a question whenever packages do usually nowadays actually provide
static libraries at all.

As I've come to understanding, nowadays many libraries doesn't allow
trivial static linkage, and that it's generally not recommended to
link statically in packages.

Thus I think we should consider updating the policy to either specify
that a development package should provide a static library if
possible, or that it shouldn't provide unless there are reasonable
reasons for inclusions.

--
Carl Fürstenberg


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTimx5UsMnwp2RBmRUvgNEvnevmPgWA@mail.gmail.com ">http://lists.debian.org/BANLkTimx5UsMnwp2RBmRUvgNEvnevmPgWA@mail.gmail.com

Static libraries in development packages
 

2011/4/16 Carl Fürstenberg:

> Thus I think we should consider updating the policy to either specify
> that a development package should provide a static library if
> possible, or that it shouldn't provide unless there are reasonable
> reasons for inclusions.

IMO Debian should err on the side of not shipping static libraries
unless they are required for particular packages.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinVfZKPoXRBPR47-zL+vwNAfbcbpw@mail.gmail.com">http://lists.debian.org/BANLkTinVfZKPoXRBPR47-zL+vwNAfbcbpw@mail.gmail.com

Static libraries in development packages
 

> 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.


> 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.


> 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

Static libraries in development packages
 

Steve M. Robbins <steve@sumost.ca> wrote:
>> 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.
[...]

Unless your are trying to link against a library that uses other
libraries ...

cu andreas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: s4un78-r4s.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/s4un78-r4s.ln1@argenau.downhill.at.eu.org

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4eu4oll.fsf@frosties.localnet">http://lists.debian.org/87k4eu4oll.fsf@frosties.localnet

Static libraries in development packages
 

On Sat, 16 Apr 2011, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Static linking of libc6 basically never makes sense. The same can be
> said for many other libs.

Yes, static linking of libc6 is a corner case that makes entirely statically
linked programs a bad idea. However mostly statically linked programs make a
lot of sense in some situations.

After Lenny was released I developed fixes for a number of serious library
bugs that caused an important application written for one of my clients to
crash. As some of the deployment platforms couldn't be guaranteed to have the
patched versions of the libraries without extreme effort (due to customers
having some interesting procedures for determining which updates were applied)
the easiest solution was to statically link every library that needed a patch.

I could have done that static linking without help from the DD in question
(making my own static libraries under /usr/local isn't THAT hard). But the
result is better if you can modify build-depends and just use static libraries
that come as part of the package.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201104162025.52648.russell@coker.com.au">http://lists.debian.org/201104162025.52648.russell@coker.com.au

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.

Regards,
-Steve

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

Static libraries in development packages
 

]] Russell Coker

Hi,

| After Lenny was released I developed fixes for a number of serious library
| bugs that caused an important application written for one of my clients to
| crash. As some of the deployment platforms couldn't be guaranteed to have the
| patched versions of the libraries without extreme effort (due to customers
| having some interesting procedures for determining which updates were applied)
| the easiest solution was to statically link every library that needed a patch.

Wouldn't just shipping known-good dynamic libs and linking with rpath
and $ORIGIN be much simpler? As a bonus, it makes it a) possible to
update the libraries if the admin wants to and b) it makes it clear what
libraries your binary depends on, without having to pull apart the
binary and guess.

Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87tydy44k4.fsf@qurzaw.varnish-software.com">http://lists.debian.org/87tydy44k4.fsf@qurzaw.varnish-software.com

Static libraries in development packages
 

On Sat, Apr 16, 2011 at 09:47:08AM +0200, Andreas Metzler wrote:
> Steve M. Robbins <steve@sumost.ca> wrote:
> >> 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.
> [...]

> Unless your are trying to link against a library that uses other
> libraries ...

In which case, since you're using pkg-config already, all you have to do is
pass --static to pkg-config --libs too.

Still pretty trivial. Remember that in the whole wide world of Unix
linkers, glibc is an *anomaly* in being able to recursively resolve ELF
dependencies; on most other systems, users have to construct the same sort
of commandline for *dynamic* linking as we do for static linking. So
there's been quite a lot of effort put into making it easy to construct
these commandlines automatically (pkg-config and libtool). libtool's method
of course has nasty side-effects for our common case that have led us to
prefer stripping out the dependency information, but pkg-config still makes
this pretty easy.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

Static libraries in development packages
 

"Steve M. Robbins" <steve@sumost.ca> writes:

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

I'm not saying you should stop doing so. Nor am I saying that for
example glib should start shipping static libs. I'm saying the current
status should be maintained as it seems to work. The users aren't
screaming.

And that status is more one of "if you feel like it" than one of "do it
unless you see a reason not to". Imho a SHOULD in policy would be too
strong for current practice.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87hb9ydplf.fsf@frosties.localnet">http://lists.debian.org/87hb9ydplf.fsf@frosties.localnet