Static Libraries?

GogglesGuy · 2010-04-29 16:34:33

I noticed quite a few static libraries in my /usr/lib folder. I thought it was the policy of Arch not install those. Or perhaps that has been changed.

jdarnold · 2010-04-29 19:28:48

Static libraries? You mean .a files? Those would only be used for compiling software. Not sure why Arch would have a policy against it.

wzff · 2010-05-03 15:53:13

I don't see why arch would not install statically linked versions of libraries. if there really is such a policy, it is stupid.

Allan · 2010-05-04 00:01:04

There is no policy about static libraries, although if they are not built be default for a piece of software, then we will probably not enable them. Saying that, we do get complaints about not including them if they are removed as there is software that unneededly forces static linking.

wzff wrote:

I don't see why arch would not install statically linked versions of libraries. if there really is such a policy, it is stupid.

Statiic libraries are crap for security, as you do not just need to fix the library, but then rebuild all the packages staticly linking to it.

MutantTurkey · 2010-05-04 13:17:08

Allan,

the same is for dynamically linked libs. they both pose possible security threats. if you have a bad static, you will have to recompile, but it would only effect the ones you have compiled. with dynamically linked libs you infect ALL programs that are linked to it.

loading a program that is static linked is often faster to load, hence the whole statli progect.

http://sta.li

Executing statically linked executables is much faster, because there are no expensive shared object lookups during exec().
Statically linked executables are portable, long lasting and fail safe to ABI changes — they will run on the same architecture even in 10 years time.
Statically linked executables use less disk space, because they only link the very small portions of static libaries into the executable that are actually used.
Statically linked executables consume less memory because their binary size is smaller.
Dynamic linking has been invented to allow changing code during runtime — don't forget that.

from Anslem Garbe's Blog

Allan · 2010-05-04 13:57:36

MutantTurkey wrote:

the same is for dynamically linked libs. they both pose possible security threats. if you have a bad static, you will have to recompile, but it would only effect the ones you have compiled. with dynamically linked libs you infect ALL programs that are linked to it.

In practise, you should recompile every package that is staticially linked to a library every time it is updated. From experience, is rare for updates not to include potential security fixes. So with static libraries, every package linked to is affected and to fix it you have to update the library and recompile everything. For shared libraries, every package linking to is is affected, but you only need to rebuild the library to fix it.

MutantTurkey wrote:

loading a program that is static linked is often faster to load, hence the whole statli progect.

Has anyone actually done the numbers on this? Especially after the shared library is cached?

I also find this naive:

Statically linked executables use less disk space, because they only link the very small portions of static libaries into the executable that are actually used.

I assume this is not including the static library any programs are built against on the system (fair enough as they are unneeded). But what if I have 30 packages on my system using libjpeg (and it is likely that you do). Then if the "small portion" linked in is more than 3% of the library size, you are at a loss in terms of binary size over your whole system. This is particular bad the the C library. The same goes for memory usage.

I see no advantage to static linking your entire system. Even portability is a poor "advatage" on a system wide scale.

wzff · 2010-05-04 14:07:59

I'm not for completely statically linking the whole system either, but:

1.) statically linked /stand is awesome. it still works when the rest of your system is fucked up so you can repair it. Just look at BSD. (IMHO Arch should have the same thing, maybe with busybox?)
2.) static libraries should be provided in case you need them. This does not mean you should link all the packages against them but provide them in addition to dynamic libraries
3.) who cares about disk space nowadays? I think the overhead of dynamic linking is definitely higher.
4.) I'm angry for the pacman devs to break pacman.static. that's exactly what I would have needed when pacman was linked against the wrong version of openssl. pacman.static does not even compile anymore and I think no attempt has been made to fix it. The last build of pacman.static is very old and can't handle .tar.xz, but newer pacman depends on packages already packaged as .tar.xz (good luck upgrading if you didn't already)

I think this rant was long enough

jdarnold · 2010-05-04 14:17:19

But unless you are building packages yourself, you don't need static libraries. If you are just downloading binaries, then static libraries don't do you any good. As a developer, I like static libraries because my software can't break "downstream", when the shared library changes. But it certainly uses more disk space, even in a small situation. Most development packages install both shared and static libraries, allowing the app developer or the person who is compiling the binary, the choice of whether they want static or shared library.

Allan · 2010-05-04 14:32:57

1) live cds/usbs do the same job, without any system/packaging overhead
2) the "low level" libraries generally have a static version supplied. The rest are really a waste.
3) "definitely" higher... strange you can compare disk space to dynamic linking overhead and rank them. I am still yet to see actual numbers on the extent of the overhead, in particular after inital caching of the library.
4) From what I can tell, pacman.static was not updated recently because xz-utils did not have a static library and more recently because no-one has done it. I think you will find that the pacman devs have done nothing break it (just removed it from the standard build process because it broke many things on non-Linux and was even broken on Linux when the libarchive libtool file was not present). Anyway, delete the main glibc libraries and try recovering with pacman static. (it is not fun... I tried it once )

Arch Linux

#1 2010-04-29 16:34:33

Static Libraries?

#2 2010-04-29 19:28:48

Re: Static Libraries?

#3 2010-05-03 15:53:13

Re: Static Libraries?

#4 2010-05-04 00:01:04

Re: Static Libraries?

#5 2010-05-04 13:17:08

Re: Static Libraries?

#6 2010-05-04 13:57:36

Re: Static Libraries?

#7 2010-05-04 14:07:59

Re: Static Libraries?

#8 2010-05-04 14:17:19

Re: Static Libraries?

#9 2010-05-04 14:32:57

Re: Static Libraries?

Board footer