> You do know that not every distribution subpackages out static link 
> libraries, right? Fedora does it, but plenty don't. For example, Debian 
> doesn't (yes, I know Debian doesn't use RPM, but you said all Linux 
> distributions).

Trust me. I'm building packages more than 25 years (Solaris old SysV and IPS 
one, rpm and debs) and you can find traces of my work even in almost all rpm 
based distributions (just try on RH centos "rpm --qa --changelog | grep 
Exactly the same policy about not using static libraries is now present in 
Debian based distributions for the same reason which I've already mentioned. 
All those changes started more than 10 years ago after Solaris *BSD started 
applying this approach.
Currently, any *-static packages are provided not to use on building packages 
but because mainly some test frameworks usually executed in %check sections are 
using few static libraries.
As I said IMO sooner even these few remaining cases will disappear as someone 
will start fixing those test units.

Ths has no relation to the fact that at the moment NONE of the other packages 
is using pkg-config dependencies listed in Libs.provate and Requires.private.

> IMO if you want to remove those private requires, then you should make them 
> something like Requires: (pkgconfig(xxx) if $name-static), otherwise nack.

I don't want to remove anything. I have no idea of where did you took this.

Again: current scripts/pkgconfigdeps.sh script by use --print-requires and 
--print-requires-private switches **together** causes adding cumulative static 
and dynamic libraries dependencies when almost all (with only a few remaining 
exceptions which IMO sooner or later will disappear as well) packages from all 
currently generated packages by any distributions are using only shared 
IMO at the moment using in .pc files Libs.private and Requires.private is 
pointless as so far I was not able to find even one source package which 
queries those fields. If you will find such example please let me know :)

In other words: pkgconfigdeps.sh script provided by rpm is generates wrong 
dependencies (way broader than it should be) using static libraries 
dependencies which do not exist in any distributions.

> That said, the top three build systems for software packaged as RPM all 
> prefer and will use pkg-config to find things if /usr/bin/pkg-config is 
> available: CMake, Meson, Autotools

Thre is no any straight connections between using those build framework, 
pkgconfigdeps.sh.  script and rpm spec files (which are using autogenerated 
If CMake, Meson, Autotools based build framework are using pkg-config command 
and in spec file is implemented using those frameworks in this exact spec file 
should be added "BuildRequires: pkgconfig" or similar.
Currently autogenerated by pkgconfigdeps.sh script dependencies are **not other 
packages built time dependencies but packages listed in BuildRequires install 
time dependencies**.

It is yet another fact related to static libraries.
Sometimes people are using statically linked binaries because non-pic code 
sometimes is 15-20% faster.
Problem is that a few years ago most of the distributions started injecting 
-pic to gcc options by providing in gcc parameters -spec=</file> in which by 
default is added use -pic/-pie.
Example from Fedora:

$ rpm --eval "%__global_compiler_flags"
-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong 
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
$ cat /usr/lib/rpm/redhat/redhat-hardened-cc1
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
This causes that even if some package provides some static library .o files 
inside ar archiives are compiled as PIC/PIE code.
Other distributions slowly follow the same path.
This last remaining reason to use statically linked binaries already have been 
killed in distributions like EL7 and Fedora.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to