Ville Skyttä wrote:
Hello,
Do the "no static linking" rules apply equally also to cases where the lib and
the executable packaged are from the same package build?
Generally speaking, yes.
From a bit more radical position: Yes, especially in these cases,
because the savings on disc-space typically show best on in these cases.
(Consider 10 statically linked application binaries + shared binaries.
In worst case, this means 11 times duplicated object files)
From a pragmatical position: There are probably 100s of packages, where
this is done unnoticed.
I'm packaging xz and intend to ship only shared libs, executables and devel
files as usual, but upstream likes to link the executables statically with the
rationale (liblzma comes from the same package, linkage would be done against
the non-shipped static liblzma created during the build):
OK, liblzma explains it ;)
## Always link the command line tool statically against liblzma. It is
## faster on x86, because no need for PIC. We also have one dependency less,
## which allows users to more freely copy the xz binary to other boxes.
Is this what they are telling you?
Unless I am mistaken, lzma+liblzma have had several API/ABI breakages in
the past. I am inclined to think there actual reasons might be
elsewhere, ...
It's easy enough to change this and link the executables dynamically, and I
haven't bothered to get any numbers to check the upstream claim. But I
suppose the primary security reason against static linkage doesn't really
apply that much when the executable and the lib are results from the same
package build, so I thought I'd ask if there are strong opinions on whether
this would be a valid exception to the no static linkage guideline or not
(none here).
Ralf
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
