Static libraries do not exist in most of the distributions and it is not the
In this exact context adding today in .pc files Requires.private and
Libs.private is pointless.
More than 14 years ago in first Solaris 10 distribution release have been no
longer shipped libc and libm.
Currently, Solaris 11 has no at all static libraries with only a few exceptions
like static flex library.
In Fedora static libraries are no longer widely used except few scenarios:
1. link static binaries used by some test suites
2. provide static libraries which have no stable ABI interface like binutils
The main reason why static linking is no longer widely used are security
reasons. In case of any CVEs in libraries used in some statically linked
binaries, it is necessary to rebuild all those binaries In case libraries as
DSO is only necessary to rebuild package which provides affected binary.
The second reason why static binaries should not be used are ABI changes. Using
static linking makes those changes way harder to maintain.
Nevertheless, in all Linux, *BSD, Solaris and other systems distributions use
Requires.private should be used only if someone is thinking that library A
provided by package B might be used to produce statically linked binaries using
the library A. Effectively this is no longer possible and if something is
linking with the library A it means in ~99.99% dynamic linking.
Generate pkgconfig dependences for dynamic linking using static linking
scenario produces redundant dependencies.
Adding automatically pkgconfig to package Requires is the second part of
redundant dependencies generated by current scripts/pkgconfigdeps.sh script.
The second change is just dumb, because the pkgconfig implementation is
necessary for even using it, and ensures that build scripts that implicitly
expect pkgconfig to be available for querying the file will work.
This is chicken and egg problem and the result of the assumption that if
package A has "Provide: pkgconfig(foo)" it does not mean that this will be used
in another package spec file *always* in form of "BuildRequires:
pkgconfig(foo)". This is not the typical case because many packages still do
not use pkgconfig on checking for example foo library.
The simple solution of this wrings solution is to add "BuildRequires:
pkgconfig" if "BuuildRequires: pkgconfig(foo)" is used. Nevertheless, this
workaround *is not needed* as current rpm-build package requires pkgconfig.
In other words on building any package from spec file which has "BuildRequires:
pkgconfig(foo)" using rpmbuild command accessibility to pkg-conf command us
guaranteed by rpm-build package Requires.
As long as install rpmbuild will cause instantly install pkgconfig spreading
across many other packages "Requires: pkgconfig" is 100% redundant.
Many packages provides .pc files and they are not used on building other
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