[Rpm-maint] [rpm-software-management/rpm] scripts/pkgconfigdeps.sh fixes (#411)

kloczek notifications at github.com
Mon Mar 12 00:14:41 UTC 2018


> 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 kloczek").
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 libraries.
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 dependencies).
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 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
$ cat /usr/lib/rpm/redhat/redhat-hardened-cc1
*cc1_options:
+ %{!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:
https://github.com/rpm-software-management/rpm/pull/411#issuecomment-372162552
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180312/d890e9bc/attachment-0001.html>


More information about the Rpm-maint mailing list