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.

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,

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.