Bug 481502

This is intentional, see libpng issue.

why do you need it?

static libraries are being phased out in the distribution, this is expected, and intentional..

I develop in a SUSE system, and run my code on several clusters. Some of the these use an older version of SUSE, others use different Linux distributions. By far the easiest way to run my binaries reliably on these systems is to compile it as a static executable.

I am also working in collaboration with a number of other people worldwide. It saves my collaborators considerable time if I can ship them working binaries which they can run. Since I can not rely on them having the same library versions (or even 32 bit versions at all), it saves us all considerable time if I can simply send them a static executable.

Why are static libraries being phased out? They are harmless to anyone who does not opt for them and invaluable in certain circumstances.

(In reply to comment #3)

> Why are static libraries being phased out? 

They are harmless to anyone who does
> not opt for them and invaluable in certain circumstances.

http://people.redhat.com/drepper/no_static_linking.html

additionally with the killer arguments in that document, we have to ensure that

1) packages that we ship do not use them, when you have a few, it is easy, when you have thousands it is a lost battle.

2) You can also split an -static subpackage, with a few is a no problem, but will thousands it is a huge, huge amount of work, that I will personally not do.

So, we started removing static libraries a few releases ago, Im personally ensuring that this task will be complete or near to completion for openSUSE 11.2.

Other distributions like Fedora try to follow a similar policy as well.

You will have to live with it.

> > They are harmless to anyone who does not opt for them and invaluable in certain circumstances.
>
> http://people.redhat.com/drepper/no_static_linking.html
> additionally with the killer arguments in that document, we have to ensure
> that

The arguments are not killer arguments. They are correct in many cases. Except, crucially the last argument:

"The often used argument about statically linked apps being more portable (i.e., can be copied to other systems and simply used since there are no dependencies) is not true since every non-trivial program needs dynamic linking at least for one of the reasons mentioned above. And dynamic linking kills the portability of statically linked apps."

which is a variation of the "no true Scotsman" fallacy. My programs are not trivial, they simply don't do anything which requires dynamic linking. I would strongly suspect that this is the case for a lot of scientific code: it loads some data, churns through a bunch of arrays for a number of hours, writes some data and then quits. The points don't apply, because the code is frequently rebuilt, security isn't an issue, a small number of instances run (binary size in memory doesn't matter), no complex features of libc are used and debugging is performed on the local machine using a dynamically linked executable.

The end result is that running on clusters becomes much more difficult, since with static linking, a rather more complex and error prone distribution process is required.

> 1) packages that we ship do not use them, when you have a few, it is easy, 
> when you have thousands it is a lost battle.

I was under the impression that dynamic linking was always used unless specified manually during the build process, but I may be mistaken.

> You will have to live with it.

That is a shame.

(In reply to comment #5)

> The end result is that running on clusters becomes much more difficult, since
> with static linking, a rather more complex and error prone distribution process
> is required.

This is because you are doing it wrong, since some time we are providing you tools to do just that in automated way, if your software is opensource, you can use the opensuse buildservice to fully automate this task and just add a repository to your machines and install updated software from there.. now if your software is propietary, you can run a private obs-server instance, it is opensource, we can also assist you in setting it up in the opensuse-buildservice mailing list.


> I was under the impression that dynamic linking was always used unless
> specified manually during the build process, but I may be mistaken.

Yes, but there are no resources to verify 3000 or more packages, this is done for sanity sake and mainteniance reasons.

see also what others are doing

http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries

Doing this also provides other side-effect advantages like much reduced packages size, bandwidth saving, less IO in the buildservers.. reduced compilation time as when static libraries are there libtool has to create separate objects for PIC and non-PIC code...there are probably many other advantages that Im missing here too ;)

*** Bug 481497 has been marked as a duplicate of this bug. ***

> This is because you are doing it wrong, since some time we are providing you
> tools to do just that in automated way, if your software is opensource, you can
> use the opensuse buildservice to fully automate this task and just add a
> repository to your machines and install updated software from there.. now if
> your software is propietary, you can run a private obs-server instance, it is
> opensource, we can also assist you in setting it up in the
> opensuse-buildservice mailing list.

The buildserver looks to be a good solution for quite a lot of tasks, but I doubt I can get it installed on all the clusters I use. Also, as far as I can tell, it builds whole packages, which will require root prelidges to install. Most people whi I know who use clusters use quite rapidly changing hand-hacked code, so I'm not sure it's the right tool in this case.

> Doing this also provides other side-effect advantages like much reduced
> packages size, bandwidth saving, less IO in the buildservers.. reduced
> compilation time as when static libraries are there libtool has to create
> separate objects for PIC and non-PIC code...there are probably many other
> advantages that Im missing here too ;)

I can see that. I also take the point that producing -static RPMs is much more work. I had a go, and it required considerably more work than removing the .a, though it is fairly mindless work. Will you accept patches to spec files? I suspect that if the process is user driven then a quite small set of libraries will end up with static versions: only those for which it is useful.

(In reply to comment #9)
> Will you accept patches to spec files? I
> suspect that if the process is user driven then a quite small set of libraries
> will end up with static versions: only those for which it is useful.

No, we are not going to add the static libs to the distro again. Let me suggest another solution for you: create a new project in the openSUSE build service, link the packages from the corresponding distribution, add spec file patches to enable static libraries and add the project repository to your installation sources.