Moved from https://bugzilla.redhat.com/show_bug.cgi?id=2143244
As noted in this thread:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/P2N35UMQVEXPILAF47RQB53MWRV2GM3J/
many packages in Fedora contain pkgconfig (*.pc) files with bad
paths. It seems two kinds of failures are common:
$ pkgconf --libs libcares
-L/usr/usr/lib64 -lcares
The path (/usr/usr/lib64) does not exist at all. Or:
$ pkgconf --libs libasyncns
-L/usr/lib -lasyncns
A package references the wrong path (64 bit package vs 32 bit /usr/lib).
It would be nice if a brp script could detect these failures.
I wrote a script (attached) which is a bit of a hack but can detect
failures in already installed packages, so that might be a starting
point:
package libasyncns refers to 32 bit path -L/usr/lib
package libwebp refers to 32 bit path -L/usr/lib
package grpc_unsecure refers to 32 bit path -L/usr/lib
package grpc++_unsecure refers to 32 bit path -L/usr/lib
package libwebpdecoder refers to 32 bit path -L/usr/lib
package libibmad refers to non-existent path -I/usr/usr/include
package libibmad refers to non-existent path -L/usr/usr/lib64
package libcares refers to non-existent path -L/usr/usr/lib64
package libibnetdisc refers to non-existent path -I/usr/usr/include
package libibnetdisc refers to non-existent path -L/usr/usr/lib64
package libwebpdemux refers to 32 bit path -L/usr/lib
package libwebpmux refers to 32 bit path -L/usr/lib
package libmlx5 refers to non-existent path -I/usr/usr/include
package libmlx5 refers to non-existent path -L/usr/usr/lib64
package gpr refers to 32 bit path -L/usr/lib
package libefa refers to non-existent path -I/usr/usr/include
package libefa refers to non-existent path -L/usr/usr/lib64
package libibumad refers to non-existent path -I/usr/usr/include
package libibumad refers to non-existent path -L/usr/usr/lib64
package librdmacm refers to non-existent path -I/usr/usr/include
package librdmacm refers to non-existent path -L/usr/usr/lib64
package valgrind refers to non-existent path -L/usr/lib64/valgrind
package grpc refers to 32 bit path -L/usr/lib
package libmlx4 refers to non-existent path -I/usr/usr/include
package libmlx4 refers to non-existent path -L/usr/usr/lib64
package grpc++ refers to 32 bit path -L/usr/lib
package libibverbs refers to non-existent path -I/usr/usr/include
package libibverbs refers to non-existent path -L/usr/usr/lib64
Version-Release number of selected component (if applicable):
rpm-4.18.0-3.fc38.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Run the attached script on a machine that has a good number of *-devel
packages installed.
Actual results:
See above.
Expected results:
These kinds of errors should be detected when the package is built,
as happens now with rpaths or unpackaged files for example.
------
Some vague stuff here:
https://github.com/rwmjones/rpm/tree/check-pkgconf
Things I cannot work out:
(1) How to get RPM's $libdir in a check script.
(2) How to get the check script to be added to __os_install_post (even the
existing check-rpaths script is not added).
[check-pkgconf.txt](https://github.com/rpm-software-management/rpm/files/14430858/check-pkgconf.txt)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2935
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/2...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
