[arch-general] Fwd: Proposal for the static library problem in Arch
Hi, Apparently I cannot post to arch-dev-public so I'm posting this here. This is a proposal for making separate packages for static libraries (with a patch for Boost C++ libraries as an example). Please see below... ---------- Forwarded message ---------- From: Daniel Liew <daniel.liew@imperial.ac.uk> Date: 28 September 2013 14:58 Subject: Proposal for the static library problem in Arch To: arch-dev-public@archlinux.org Hi All, I've noticed recently that there have been problems with static libraries being removed from packages. E.g. https://bugs.archlinux.org/task/35257 https://bugs.archlinux.org/task/34491 https://mailman.archlinux.org/pipermail/arch-general/2010-September/016152.h... https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024552.ht... I've only just joined to mailing list so I couldn't find a way to reply to the emails I have never received so I thought I'd just start a new thread (apologies). I see both sides of the argument as valid: - Lots of people don't need the static libraries so why include them in packages, they are wasting space. On the other hand... - Some developers need static libraries to build their projects. In my case I needed to build a static library that has dependencies on the Boost library. I do not want unresolved symbols to Boost C++ library functions in there. I really don't think that completely removing static libraries from the repositories is the correct approach because it I believe the choice of whether or not to have static libraries on your system should be down to the user and not the distro (yes I'm aware I could compile boost myself... that's what I'm doing right now but what happened to "Keep it Simple"? If I wanted to compile loads of stuff from scratch I'd be using Gentoo). So my proposal is this: For popular packages that have can build static libraries and shared libraries, build both but put the static libraries into their own "*-staticlibs" package and the *-libs" packages should contain only shared libraries. For example for boost you would have boost : Development headers + other files boost-libs : Boost shared libraries boost-static-libs : Boost static libraries The boost package dependencies would be set to be dependent on boost-libs but **not** boost-staticlibs so the static libraries would only be installed if the user explicitly installed them. So everybody wins. Static libraries are not installed by default saving disk space but the static libraries are available as packages should the user decide they need them. Looking at the PKGBUILD syntax this looked quite trivial to do so I've done it for Boost and the patch is attached (apply against boost 1.54.0-3 PKGBUILD) Thoughts? Thanks, Dan Liew
[2013-09-28 15:26:56 +0100] Delcypher:
For popular packages that have can build static libraries and shared libraries, build both but put the static libraries into their own "*-staticlibs" package and the *-libs" packages should contain only shared libraries. For example for boost you would have
boost : Development headers + other files boost-libs : Boost shared libraries boost-static-libs : Boost static libraries
I am strongly against this proposal. For many reasons, including those in the page Allan pointed to, dynamic libraries should be the default on Arch systems, and they should be the only supported type of library. Users who wish to build and use static libraries are of course free to do so, but should not expect Arch will do this work for them. Splitting packages as you suggests puts more burden on the developers, build process, and mirror bandwidth - with very few users benefiting. But, hey, that's fine: there is tons of great stuff in the AUR which is not officially supported by Arch Linux, simply because we do not have the resources to support everything - so we just focus on what most people care. And anybody is free to come along and "unofficially" support anything else... -- Gaetan
On 28/09/13 19:27, Gaetan Bisson wrote:
[2013-09-28 15:26:56 +0100] Delcypher:
I am strongly against this proposal. For many reasons, including those in the page Allan pointed to, dynamic libraries should be the default on Arch systems, and they should be the only supported type of library.
Which page did Allan refer to? I cannot see a reply from Allan in this thread. The only link I could find in the other threads was http://www.plan9.bell-labs.com/wiki/plan9/why_static/ and that wasn't really in favour of shared libraries.
Users who wish to build and use static libraries are of course free to do so, but should not expect Arch will do this work for them. Splitting packages as you suggests puts more burden on the developers, build process, and mirror bandwidth - with very few users benefiting.
But, hey, that's fine: there is tons of great stuff in the AUR which is not officially supported by Arch Linux, simply because we do not have the resources to support everything - so we just focus on what most people care. And anybody is free to come along and "unofficially" support anything else...
I am disappointed that is the consensus but if the majority of Arch developers share the view that static libraries should be removed entirely then there is little I can do to change things. I'll have to maintain my own boost packages for now. Thanks, Dan.
[2013-09-28 22:25:55 +0100] Dan Liew:
On 28/09/13 19:27, Gaetan Bisson wrote:
[2013-09-28 15:26:56 +0100] Delcypher:
I am strongly against this proposal. For many reasons, including those in the page Allan pointed to, dynamic libraries should be the default on Arch systems, and they should be the only supported type of library.
Which page did Allan refer to? I cannot see a reply from Allan in this thread.
Right; it was in the "glibc 2.18-5 question" thread: http://www.akkadia.org/drepper/no_static_linking.html -- Gaetan
Am 28.09.2013 16:26, schrieb Delcypher:
I really don't think that completely removing static libraries from the repositories is the correct approach because it I believe the choice of whether or not to have static libraries on your system should be down to the user and not the distro
This has been discussed more than once, always with the same result. Static libraries are a dead end and are going away.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28/09/13 19:32, Thomas Bächler wrote:
Am 28.09.2013 16:26, schrieb Delcypher:
I really don't think that completely removing static libraries from the repositories is the correct approach because it I believe the choice of whether or not to have static libraries on your system should be down to the user and not the distro
This has been discussed more than once, always with the same result. Static libraries are a dead end and are going away.
I think it's a shame people think that static libraries are completely dead. Although I agree that shared libraries are usually preferable to static libraries there are circumstances where their use is warranted (e.g. building portable executables). I would also be remiss if I did not point out a prominent software project that I doubt will ever switch to using shared libraries completely which is LLVM. [1] explains the reasoning behind using static libraries which is completly sensible. I notice that the Arch llvm package still has it's static libraries. Just my two cents. [1] 11.4.2. LLVM is a Collection of Libraries http://www.aosabook.org/en/llvm.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJHTyUACgkQnsttD+nT/6MkGQCgv8U+coh7AnL694bCJzue1ZL2 nkgAn0r8PiUE985dr7JLYGlLy+opivpv =CHx1 -----END PGP SIGNATURE-----
On 2013-09-28 23:50, Dan Liew wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 28/09/13 19:32, Thomas Bächler wrote:
Am 28.09.2013 16:26, schrieb Delcypher:
I really don't think that completely removing static libraries from the repositories is the correct approach because it I believe the choice of whether or not to have static libraries on your system should be down to the user and not the distro
This has been discussed more than once, always with the same result. Static libraries are a dead end and are going away.
I think it's a shame people think that static libraries are completely dead. Although I agree that shared libraries are usually preferable to static libraries there are circumstances where their use is warranted (e.g. building portable executables).
I would also be remiss if I did not point out a prominent software project that I doubt will ever switch to using shared libraries completely which is LLVM. [1] explains the reasoning behind using static libraries which is completly sensible.
I notice that the Arch llvm package still has it's static libraries.
Just my two cents.
[1] 11.4.2. LLVM is a Collection of Libraries http://www.aosabook.org/en/llvm.html
I don't think "static library" means what you think it means. $ ldd `which clang` linux-vdso.so.1 (0x00007fff933fe000) libLLVM-3.3.so => /usr/bin/../lib/libLLVM-3.3.so (0x00007fd694c3c000) ^^^^^^^^^^^^^^ libpthread.so.0 => /usr/bin/../lib/libpthread.so.0 (0x00007fd694a1e000) libstdc++.so.6 => /usr/bin/../lib/libstdc++.so.6 (0x00007fd69471a000) libgcc_s.so.1 => /usr/bin/../lib/libgcc_s.so.1 (0x00007fd694504000) libc.so.6 => /usr/bin/../lib/libc.so.6 (0x00007fd694159000) libz.so.1 => /usr/bin/../lib/libz.so.1 (0x00007fd693f43000) libffi.so.6 => /usr/bin/../lib/libffi.so.6 (0x00007fd693d3b000) libdl.so.2 => /usr/bin/../lib/libdl.so.2 (0x00007fd693b37000) libm.so.6 => /usr/bin/../lib/libm.so.6 (0x00007fd693834000) /lib64/ld-linux-x86-64.so.2 (0x00007fd696502000) Regards,
On 2013-09-28 23:50, Dan Liew wrote:
[1] 11.4.2. LLVM is a Collection of Libraries http://www.aosabook.org/en/llvm.html
My last reply was flippant. Apologies for that. However, I don't see any mention of why static libraries should supposedly be better for LLVM at the above URL. Can you direct us to a specific section/sentence/whatever of that document? Regards,
My last reply was flippant. Apologies for that.
Huhh I didn't realise clang used LLVM as a shard library. I guess my perspective is slightly skewed because I work on another LLVM based project that uses static libraries instead (the project uses an old version LLVM).
However, I don't see any mention of why static libraries should supposedly be better for LLVM at the above URL. Can you direct us to a specific section/sentence/whatever of that document?
There is the sentence "Once the set of optimizations is chosen (and similar decisions are made for the code generator) the image processing compiler is built into an executable or dynamic library. Since the only reference to the LLVM optimization passes is the simple create function defined in each .o file, and since the optimizers live in .a archive libraries, only the optimization passes that are actually used are linked into the end application, not the entire LLVM optimizer" But there isn't anything there that explicitly states a preference for static libraries over shared ones. So I guess this example was not as good as I thought it was. Regards.
On Sat, 2013-09-28 at 15:26 +0100, Delcypher wrote:
should be down to the user and not the distro (yes I'm aware I could compile boost myself... that's what I'm doing right now but what happened to "Keep it Simple"? If I wanted to compile loads of stuff from scratch I'd be using Gentoo).
So my proposal is this:
For popular packages that have can build static libraries and shared libraries, build both but put the static libraries into their own "*-staticlibs" package and the *-libs" packages should contain only shared libraries. For example for boost you would have
boost : Development headers + other files boost-libs : Boost shared libraries boost-static-libs : Boost static libraries
IMO, sounds like a good idea in theory but in practice it is the opposite of "Keep it Simple". Have you ever tried to compile something on Ubuntu to end up fetching an endless number of libXXX-devel packages? I hate doing that. Disk space is cheap. Better have everything everyone will ever need from a given OSS package. Greetings,
participants (6)
-
Bardur Arantsson
-
Dan Liew
-
Delcypher
-
Gaetan Bisson
-
Olivier Langlois
-
Thomas Bächler