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). > *snip* > > 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 > not true. > > 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. > *snip* > > 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 > next release. > 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: https://www.redhat.com/archives/fedora-extras-list/2006-October/msg00048.html 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. static linking. +1 for the foo-devel-static RPM concept. Regards, Japheth Cleaver, Airband Communications cleaver@xxxxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
