the meaning of pkgconfig's Libs fields
by Zbigniew Jędrzejewski-Szmek
Hi,
various .pc files that we ship contain a lot of stuff in the Libs and
Libs.private field don't make much sense to me. I started looking at
the documentation, and the documentation is very scarce, and what is
there doesn't seem to have been thought out at all. I'm writing my
observations and questions below.
pc(5) says:
Libs: Required linking flags for this package. Libraries this
package depends on for linking against it, which are not
described as dependencies should be specified here.
Libs.private: Required linking flags for this package that are
only required when linking statically. Libraries this
package depends on for linking against it statically, which
are not described as dependencies should be specified here.
"described as dependencies" here means "not listed in Requires and
Requires.private fields, which are used to specify dependencies on
other pkgconf projects.
On the face, this seems reasonable, but there's other documentation
that has a different spin. E.g.
https://people.freedesktop.org/~dbn/pkg-config-guide.html says:
Libs: The link flags specific to this package and any required
libraries that don't support pkg-config.
Libs.private: The link flags for private libraries required by
this package but not exposed to applications. The same
rule as Cflags applies here.
"required" here refers to using Requires and Requires.private to
list other .pc files.
Neither of the above approaches seems to be consistent with how we
actually use .pc files, and even not much consistent with how they
could be reasonably used:
1. pc(5) talks about "package", as if one would want to link to a
whole "package" instead one of the specific library files provided
by a package. Thankfully most .pc files only list one "-l" in Libs.
(Counterexamples: tbbmalloc_proxy.pc says 'Libs:-ltbbmalloc_proxy -ltbbmalloc',
and mit-krb5.pc says Libs:-lkrb5 -lk5crypto -lcom_err.)
The concept of having multiple libs in Libs in itself is borked:
either the libraries are functional separately, in which case they
would better have separate .pc files, so that the programs using
those libraries can link to the one they need, or if they are not
functional separately, the one that exposes functionality that is
useful externally should be advertised (the others will be pulled
in automatically by the linker).
2. In practice, most .pc files that list multiple things in Libs seem to
be doing exposing their own link dependencies there. For example
mono-2.pc says 'Libs: -L${libdir} -lmono-2.0 -lm -lm -lpthread',
and indeed ldd /usr/lib64/libmono-2.0.so says it is linked to libm.so.6.
Of course this doesn't mean that programs using libmono would need to
be linked to libm themselves.
Items 1 + 2 are promoting overlinking, i.e. adding either unneeded
libraries, or libraries that are used indirectly, to linker flags for
some object being linked.
If we take the pc(5) definition at its word, the Libs.private lines
are even more broken in Fedora, because we almost never provide static
libraries.
Looking at Requires and Requires.private, there is more strangeness.
pc(5):
Requires: Required dependencies that must be met for the package
to be usable. All dependencies must be satisfied or the
pkg-config implementation must not use the package.
Requires.private: Required dependencies that must be met for the
package to be usable for static linking. All dependencies
must be satisfied or the pkg-config implementation must
not use the package for static linking.
To a large extent pkgconfig files are duplicating dependency logic
that is already provided by distro packaging (rpm in our case). This
would seem like an OK idea: upstreams specify which libraries they
need and downstreams use it.
It seems not to work in practice: e.g. atk-bridge-2.0.pc specifies
Requires.private: dbus-1 >= 1.5, atspi-2 >= 2.33.2, atk >= 2.36.0,
glib-2.0 >= 2.32.0, gmodule-2.0 >= 2.0.0, gobject-2.0 >= 2.0.0
which is translated into:
$ rpm -qRf /usr/lib64/pkgconfig/atk-bridge-2.0.pc
/usr/bin/pkg-config
pkgconfig(atk) >= 2.36.0
pkgconfig(atspi-2) >= 2.33.2
pkgconfig(dbus-1) >= 1.5
pkgconfig(glib-2.0) >= 2.32.0
pkgconfig(gmodule-2.0) >= 2.0.0
pkgconfig(gobject-2.0) >= 2.0.0
...
Two problems:
3. We autogenerate a dependency on /usr/bin/pkg-config for -devel.
Logic is reversed here: the -devel package **provides** something
that it consumed by pkg-config. Dependencies are from a consumer to
the providing entity.
4. The -devel subpackage pulls in atk-devel, at-spi2-core-devel,
dbus-devel, glib2-devel, and glib2-devel. Most of those dependencies
are completely pointless. The only reason why one header package
would require another header package is when the headers it provides
#include other headers. at-spi2-atk-devel has a single header file,
with '#include <glib.h>'. It thus should have a dependency on 'pkgconfig(glib-2.0)',
and all the other deps generated from Requires.private just inflate
the build root. (If glib.h or libglib-2.0.so in turn require other
things for themselves, those dependencies will be specified by glib2.rpm.)
And finally, we get to stuff which is included in Libs:
/usr/lib64/pkgconfig/libresample.pc
Libs: -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lresample -lm
/usr/lib64/pkgconfig/libpsx.pc
Libs: -L${libdir} -lpsx -lpthread -Wl,-wrap,pthread_create
/usr/lib64/pkgconfig/ruby.pc
DLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
Libs: ${DLDFLAGS} ${LIBRUBYARG_SHARED} ${LIBS}
/usr/lib64/pkgconfig/libresample.pc
Libs: -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -lresample -lm
/usr/lib64/pkgconfig/socket_wrapper.pc
Libs: lib64/libsocket_wrapper.so
/usr/lib/pkgconfig/gmodule-2.0.pc
Libs: -Wl,--export-dynamic
Those seems to be all errors: redhat-hardened-ld is supposed to be
used in package builds, not exposed for user compilations.
lib64/libsocket_wrapper.so cannot be resolved. And other link flags
that change the resulting binary is not the something that libraries
should specify.
To summarize:
- Re 3: drop the generator for the reversed dep?
- Re 2: flat everything that is not -l, -L, in Libs with rpmlint?
Zbyszek
2 years, 4 months
conditional require
by przemek klosowski
During recent major version update, some files were moved from
<package>-doc to <package>, and as a result updates of <package> fail
due to a file conflict. Manual update of <package>-doc resolves this, of
course.
A simple solution would be to declare that <package>
Required: package-doc >= 6.0.0
but that would force the install of the docs package if it wasn't
already there.
Is there a way to declare a dependency only if the other package is
present/installed? Would
Obsoletes: package-doc < 6.0.0
be the right thing to do?
2 years, 4 months
gcc-12.0.0-0.4.fc36 in rawhide
by Jakub Jelinek
Hi!
gcc 12 snapshot has landed as the system compiler into rawhide today.
GCC 12 is going to enter its stage4 development phase (only regression
and documentation bugfixes allowed) on Monday 17th, so there should be
just those bugfixes and not new features etc. anymore.
https://gcc.gnu.org/gcc-12/changes.html lists important changes,
most important is probably that vectorization is enabled at -O2 now
which is the option with most of the distribution is built with.
https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
some cases where people need to adjust their code. Other things
include the usual C++ header changes, where previously some standard
header included some other header as an implementation detail but it doesn't
any longer and so code that relied on such indirect include that isn't
required by the standard needs to include the header that provides whatever
it relies on. Or e.g. packages using -Werror where new warnings are
reported with the newer compiler and -Werror results in build failures.
If there are bugs on the compiler side, please let me know immediately,
so that those bugs can be fixed before the mass rebuild next week.
Another important thing I wanted to say is that we'd like to switch
ppc64le from the numerically problematic IBM extended long double to
IEEE 754 quad long double. This is an ABI change. Some libraries
are already built so that they support both ABIs at the same time,
including glibc, libstdc++, libgcc, libgfortran etc.
For other libraries and binaries, the compiler, assembler and linker
will notice if they use long double and flag them as using either
IBM or IEEE long double and linker (or I think dynamic linker too)
might complain when things are mixed.
Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
but the glibc/gcc libraries are built compatibly with both.
We'd like to configure gcc shortly before the mass rebuild with
--with-long-double-format=ieee so that it will default to
-mabi=ieeelongdouble, probably on a side-tag build first, and it
will be highly desirable to rebuild at least some of the most commonly
used library packages in the order of dependencies there, otherwise
I'd be afraid the mass rebuild could fail for way too many packages
(as the mass rebuild doesn't do dependency order rebuilds but just
goes through packages alphabetically or so).
Any suggestions on which packages have commonly used library packages
that use long double?
readelf -A on libraries on ppc64le prints either nothing (either
the library is thought not to use long double or supports both ABIs
transparently or hasn't been rebuilt for some years), or
Attribute Section: gnu
File Attributes
Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
for libraries (or binaries or object files) that use IBM long double
only or
Attribute Section: gnu
File Attributes
Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double
for IEEE long doubles.
So I think we want to rebuild on a side-tag packages that
provide shared libraries used by hundreds of other packages that
are
Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double
right now.
Jakub
2 years, 4 months
How to handle a few files moving from one package to another?
by Steven A. Falco
When updating from KiCad 5 to KiCad 6, a few files have moved from the kicad-doc package to the main kicad package.
If someone has KiCad 5 and its documentation package installed, and then tries to just upgrade the main package to KiCad 6 (without also updating the docs), they get an error message like:
Error: Transaction test error:
file /usr/share/doc/kicad/scripts/lib_convert.py from install of kicad-1:6.0.1-1.fc35.x86_64 conflicts with file from package kicad-doc-1:5.1.12-1.fc35.noarch
file /usr/share/doc/kicad/scripts/test_kicad_plugin.py from install of kicad-1:6.0.1-1.fc35.x86_64 conflicts with file from package kicad-doc-1:5.1.12-1.fc35.noarch
I think the correct solution is to put this into the main package:
Obsoletes: kicad-docs < 6.0.0
Is that correct, or is there a better way to handle it?
Steve
2 years, 4 months
Intent to orphan gnu-efi
by Robbie Harwood
Hello, we plan to orphan gnu-efi shortly after I finish fixing the
FTBFS. There do not appear to be any consumers:
# dnf repoquery --repo=rawhide{,-source} --whatrequires gnu-efi{,-devel} --source
Last metadata expiration check: 0:05:32 ago on Tue 25 Jan 2022 01:09:26 PM EST.
gnu-efi-3.0.11-7.1.fc36.src.rpm
#
Be well,
--Robbie
2 years, 4 months
ppc64le build failures in the mass rebuild
by Dan Horák
Hi,
as there are still a number of ppc64le build failures from the mass
rebuild, please make the FTBFS bugs block the "PPCTracker" so we know
about them.
Here is what we know so far
- segfaulting ICE with "during RTL pass: final" or not being able to
assemble the sources, those should be fixed in gcc-12.0.1-0.3.fc36, so
a rebuild should fix them
- issues with "__LDBL_REDIR1_DECL", they are caused by the bundled
gnulib not being compatible with the installed glibc, a fix is to
replace the bundled cdefs.h with more recent one
(https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/cdefs.h;h=...),
seen eg in lftp (https://bugzilla.redhat.com/show_bug.cgi?id=2045780)
or dhcpd-pools (https://bugzilla.redhat.com/show_bug.cgi?id=2045310)
- various "long double" related issues, some might be fixed by building
in proper order, but some will need further investigation, a corner
case in libffi should be fixed in
https://src.fedoraproject.org/rpms/libffi/pull-request/6
- various "vector" related issues/ICE, for example in cantera or mame
- libtool de-duplicating internal libs, when it shouldn't, like
/usr/bin/ld: /usr/lib/gcc/ppc64le-redhat-linux/12/libgcc.a(float128-ifunc.o):
(.data+0x0): undefined reference to
`__parse_hwcap_and_convert_at_platform',
this is a generic problem, a fix is proposed in
https://bugzilla.redhat.com/show_bug.cgi?id=2047389
and workaround is
https://src.fedoraproject.org/rpms/codeblocks/c/c8f36775a26f79d598e886a82...
- something else?
Thanks,
Dan
2 years, 4 months
RFE: CMake AutoRequires?
by Kevin Kofler
Hi,
when working on finally fixing Trojitá to build (it had been FTBFS since
F34, so removal was impending), I have noticed that the Akonadi contacts
plugin was not getting built because of missing transitive build
dependencies:
https://bugzilla.redhat.com/show_bug.cgi?id=2046299
https://bugzilla.redhat.com/show_bug.cgi?id=2046310
https://bugzilla.redhat.com/show_bug.cgi?id=2046574
They all have in common that FooConfig.cmake wants the CMake package Bar,
but foo-devel does not Require bar-devel. So building against Foo does not
work out of the box, only when manually BRing also bar-devel.
The thing is, we have had for a while AutoProvides scripts for CMake that
automatically let bar-devel Provide cmake(Bar). This is already used in many
places. What is missing, though, is corresponding AutoRequires, so that foo-
devel automatically Requires: cmake(Bar) if FooConfig.cmake requires Bar.
Would it not make sense to add such an AutoRequires script?
Kevin Kofler
2 years, 4 months
Carla compilation fails with: /usr/bin/ld: warning: libgraphite2.so.3,
needed by /lib/libharfbuzz.so.0
by Martin Gansser
Hi,
I'am trying to compile Carla [1] on f35, but this fails with this eror message [2]:
/usr/bin/ld: warning: libgraphite2.so.3, needed by /lib/libharfbuzz.so.0, not found (try using -rpath or -rpath-link)
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_advance_X'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_face_featureval_for_lang'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_face_find_fref'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_destroy'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_first_slot'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_seg_n_slots'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_can_insert_before'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_origin_Y'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_next_in_segment'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_make_face_with_ops'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_make_seg'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_after'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_origin_X'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_face_destroy'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_fref_set_feature_value'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_gid'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_featureval_destroy'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_before'
/usr/bin/ld: /lib/libharfbuzz.so.0: undefined reference to `gr_slot_advance_Y'
collect2: error: ld returned 1 exit status
files are existing:
$ rpm -qf /usr/lib/libgraphite2.so.3 /usr/lib64/libgraphite2.so.3
graphite2-1.3.14-8.fc35.i686
graphite2-1.3.14-8.fc35.x86_64
How can i fix this ?
[1] https://martinkg.fedorapeople.org/Packages/Carla/Carla.spec
[2] https://martinkg.fedorapeople.org/Packages/Carla/carla-compile-erros.txt
Regards
Martin
2 years, 4 months