Shipping static libraries

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Shipping static libraries

Loïc Minier
        Hi,

 A while ago, we discussed shipping static libraries for things such as
 gtk.  Sadly, this dicsussion probably happened mainly on IRC, and left
 no track on the consensus.  I don't recall exactly what we reached, but
 I recall that we faced these main issues:

1/ static libraries should be avoided in general, as security support is
   made harder by its use
2/ static libraries are huge in size, especially things such as gtk
3/ static gtk seemed unusable back then

 Josselin underlined that policy says that "The static library
 (libraryname.a) is usually provided in addition to the shared version."
 and added that this implies there's no obligation.

 I think we should have some consistency so that static libs are usable.

 Point 1/ is irrelevant in the discusison of _shipping_ the static libs,
 point 3/ was proved wrong by vorlon who was able to build an app using
 the static gtk version.

 Point 2/ is the hardest as not only archive size is at hand, but also
 buildd disk space (and time) needed to build the static copy.

 I propose we satisfy wishlist requests against smaller libraries such
 as #337025, when that obviously won't cause too much buildd pressure,
 and avoid doing it in the contrary case (eg. gtk or other large
 packages).

   Cheers,
--
Loïc Minier <[hidden email]>
"What do we want? BRAINS!    When do we want it? BRAINS!"


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Sven Luther
On Thu, Nov 03, 2005 at 10:23:28AM +0100, Loïc Minier wrote:

>         Hi,
>
>  A while ago, we discussed shipping static libraries for things such as
>  gtk.  Sadly, this dicsussion probably happened mainly on IRC, and left
>  no track on the consensus.  I don't recall exactly what we reached, but
>  I recall that we faced these main issues:
>
> 2/ static libraries are huge in size, especially things such as gtk
>
>  Point 2/ is the hardest as not only archive size is at hand, but also
>  buildd disk space (and time) needed to build the static copy.

Do you really think this is worse than X shipping static libraries ? I mean
building X already used to need many GB of free disk space, and i have some
doubts that gtk+ will be more disk-space hungry, but i could be wrong.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Loïc Minier
On Thu, Nov 03, 2005, Sven Luther wrote:
> Do you really think this is worse than X shipping static libraries ? I mean
> building X already used to need many GB of free disk space, and i have some
> doubts that gtk+ will be more disk-space hungry, but i could be wrong.

 Yes, gtk needs more space than xorg.  Have a look at:
 http://buildd.debian.org/fetch.php?&pkg=gtk%2B2.0&ver=2.6.2-1&arch=m68k&stamp=1107973275&file=log&as=raw
 (2451432k)

 http://buildd.debian.org/fetch.php?&pkg=xorg-x11&ver=6.8.2.dfsg.1-9&arch=m68k&stamp=1129641779&file=log&as=raw
 (1660956k)

--
Loïc Minier <[hidden email]>
"What do we want? BRAINS!    When do we want it? BRAINS!"


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Ross Burton
In reply to this post by Loïc Minier
On Thu, 2005-11-03 at 10:23 +0100, Loïc Minier wrote:
>  point 3/ was proved wrong by vorlon who was able to build an app using
>  the static gtk version.

Did it load images?  The gdk-pixbuf loaders are dlopened.  Was Pango
statically linked? That dlopens the modules the scripts.  Obviously the
application used the default theme, as theme engines are dlopened.

If the static libraries handle these cases then excellent, but otherwise
a non-trivial static GTK+ application isn't usable.

Ross
--
Ross Burton                                 mail: [hidden email]
                                          jabber: [hidden email]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Sven Luther
In reply to this post by Loïc Minier
On Thu, Nov 03, 2005 at 10:50:28AM +0100, Loïc Minier wrote:

> On Thu, Nov 03, 2005, Sven Luther wrote:
> > Do you really think this is worse than X shipping static libraries ? I mean
> > building X already used to need many GB of free disk space, and i have some
> > doubts that gtk+ will be more disk-space hungry, but i could be wrong.
>
>  Yes, gtk needs more space than xorg.  Have a look at:
>  http://buildd.debian.org/fetch.php?&pkg=gtk%2B2.0&ver=2.6.2-1&arch=m68k&stamp=1107973275&file=log&as=raw
>  (2451432k)
>
>  http://buildd.debian.org/fetch.php?&pkg=xorg-x11&ver=6.8.2.dfsg.1-9&arch=m68k&stamp=1129641779&file=log&as=raw
>  (1660956k)

Well, not much more though, and i remember older X builds which needed well
over 2GB (i think XFree86 needed 4GB or so back in those days, where i still
had my apus amiga).

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Gabor Gombas
In reply to this post by Ross Burton
On Thu, Nov 03, 2005 at 09:55:07AM +0000, Ross Burton wrote:

> Did it load images?  The gdk-pixbuf loaders are dlopened.  Was Pango
> statically linked? That dlopens the modules the scripts.  Obviously the
> application used the default theme, as theme engines are dlopened.
>
> If the static libraries handle these cases then excellent, but otherwise
> a non-trivial static GTK+ application isn't usable.

This is often not the issue though. It is quite common to build only
_some_ of the libraries statically. Module loading is an orthogonal
issue, statically linked applications may still use dynamically loaded
modules.

In fact, right now you cannot build a fully static application on a
Debian system as glibc will always load the NSS modules dynamically
(unless you rebuild glibc with the --enable-static-nss option).

I'm not certain about the level of module ABI compatibility gtk
provides, but for example, it might be possible to link gtk-2.8
statically into an application and still be able to run the binary on a
system that only has gtk-2.4 installed. In this case, the application
can use any new features from gtk-2.8 while it still uses the modules
from gtk-2.4.

Gabor

--
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Chipzz
In reply to this post by Loïc Minier
On Thu, 3 Nov 2005, Loïc Minier wrote:

> 3/ static gtk seemed unusable back then

A whole lot of years back, when I tried to statically link a gnome 1.4
application (back then it was still on redhat, before I discovered the
joy that was debian), it did not even link at all since the dynamically
generated Corba code had conflicting symbols (which I very much doubt
has changed since then).

kr,

Chipzz AKA
Jan Van Buggenhout
--

------------------------------------------------------------------------
                 UNIX isn't dead - It just smells funny
                           [hidden email]
------------------------------------------------------------------------
"Baldric, you wouldn't recognize a subtle plan if it painted itself pur-
 ple and danced naked on a harpsicord singing 'subtle plans are here a-
 gain'."


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Shipping static libraries

Loïc Minier
In reply to this post by Ross Burton
On Thu, Nov 03, 2005, Ross Burton wrote:
> If the static libraries handle these cases then excellent, but otherwise
> a non-trivial static GTK+ application isn't usable.

 Ok, I'm happy I already asked for clarification on usability of the
 resulting static library in #337025 (against libgtksourceview), and I
 think this criteria should be met.

   Thanks,
--
Loïc Minier <[hidden email]>
"What do we want? BRAINS!    When do we want it? BRAINS!"


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

SUMMARY: Shipping static libraries

Loïc Minier
In reply to this post by Loïc Minier
        Hi,

 The summary of this discussion is along the lines of:
 - static libraries are:
   . not mandatory
   . helpful for a few people
   . harmful for security
 - static libraries are a burden for buildds since they require more
   time and space to build
 - static libraries are taking more place in the archive and on end-user
   systems

 I propose we try having the following approach:
 - it's always up to the maintainer to decide to ship or don't ship the
   static version, but we should try being consistent among packages so
   that one gets a useful set of static libraries, or none
 - if a wishlist bug is opened requesting static libraries, then the
   maintainer should check:
   . the size of the package and the impact on buildds and binary
     packages sizes: if the package is going to take more time and space
     to build, will all buildds be able to follow?
   . the usability of the resulting staic libraries: can a non-trivial
     and useful program be statically linked with the resulting static
     library (especially with respect to dynamically loaded modules in
     libraries loading some modules dynamically)

   Cheers,
--
Loïc Minier <[hidden email]>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]