Ulrich Drepper wrote:
Before going on I want to make one thing clear: there is no problem
whatsoever if the code you're linking with statically is also controlled
by yourself. Especially if the library code comes in the same problem.
In this situation it is even a huge advantage to link statically and
avoid the silly DSO which is used just in the programs of the package.
This is something which likely applies to many of the users of
heterogeneous computing environments (numeric stuff or not).
There is nothing which you can do with static linking that you cannot do
with a dynamically linked executable as well. The other direction is
As for automatic -devel-static RPM, this is wrong as well. Yes, for a
transitional period some -devel-static RPMs might be needed. But each
and every one of them must be justified (e.g., no gnome/kde package
should have them, period). And you even need to dig in deeper: each .a
file on those RPMs needs to be justified. For instance, glibs's RPMs
should not contain libpthread.a at all. This code never really worked
as well as the dynamically linked code.
I want to see a default policy of dropping all .a files (except special
ones like libc_nonshared.a, of course, which are needed during dynamic
linking). Everybody having problems with any specific situation will
have to make her/his point why a -devel-static package should be
provided. If the exception is granted it has to be revisited for the
I don't see how the first two paragraphs here comport with the remaining
ones. If people are going to be able to compile things statically then
they need to be able to.
This is not dissimilar to a discussion on fedora-extras last month:
There are cases, either when developing software YOU'VE written or when
using software written with a static mindset in mind (DJB-ware comes to
mind, but anything else doing a lot of exec image replacement from one
tiny binary to another), where static compilation is useful and provides
a not-insignificant speed improvement. (Our mail server saw a
performance boost of about 20% when we statically linked our process chain.)
We should not remove the ability to easily install static libraries from
the Fedora/Fedora-Extras system simply due to someone's crusade against
it. If a Fedora user is to be trusted with Development Packages, then
they should be trusted to "know what they're doing" wrt dynamic vs.
+1 for the foo-devel-static RPM concept.