David (CC'd) is working on the Fedora RISC-V port and he noticed that some *.pc files in Fedora contain incorrect paths. For example[1]:
$ pkgconf --libs libcares -L/usr/usr/lib64 -lcares
$ pkgconf --libs libasyncns -L/usr/lib -lasyncns
On non-riscv64 this happens to work because the default search path includes the right directory anyway (eg. /usr/lib64).
On riscv64 this causes build failures since meson seems to go off and search for the *.so files and then tries to construct an absolute path to them (I'm not sure if this isn't a bug in meson TBH). For example:
http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782
This problem appears to be widespread. I scanned just the *-devel packages that I happen to have installed, results below. Not sure how to scan all *-devel packages in Fedora.
What should we do here? Is it worth having an RPM build step that checks for this problem?
Rich.
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 libmlx5 refers to non-existent path -I/usr/usr/include package libmlx5 refers to non-existent path -L/usr/usr/lib64 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 libmlx4 refers to non-existent path -I/usr/usr/include package libmlx4 refers to non-existent path -L/usr/usr/lib64 package libibverbs refers to non-existent path -I/usr/usr/include package libibverbs refers to non-existent path -L/usr/usr/lib64
[1] Proposed fix for c-ares issue: http://fedora.riscv.rocks:3000/rpms/c-ares/commit/e5acf4bc513b425793a30fa1fe...
On Wed, Nov 16, 2022 at 10:34:42AM +0000, Richard W.M. Jones wrote:
David (CC'd) is working on the Fedora RISC-V port and he noticed that some *.pc files in Fedora contain incorrect paths. For example[1]:
$ pkgconf --libs libcares -L/usr/usr/lib64 -lcares
$ pkgconf --libs libasyncns -L/usr/lib -lasyncns
Actually I realise my script doesn't catch this case (32 bit path) since the path exists. I hacked it up to catch this and the complete results are:
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
Rich.
The following reflect an upstream bug in grpc:
package grpc_unsecure refers to 32 bit path -L/usr/lib package grpc++_unsecure refers to 32 bit path -L/usr/lib package gpr refers to 32 bit path -L/usr/lib package grpc refers to 32 bit path -L/usr/lib package grpc++ refers to 32 bit path -L/usr/lib
Now that I know about the problem, I was able to submit a PR upstream[1] to fix it. I will patch and update the Fedora packages over the next few days.
[1] https://github.com/grpc/grpc/pull/31671
On 11/16/22 06:01, Richard W.M. Jones wrote:
On Wed, Nov 16, 2022 at 10:34:42AM +0000, Richard W.M. Jones wrote:
David (CC'd) is working on the Fedora RISC-V port and he noticed that some *.pc files in Fedora contain incorrect paths. For example[1]:
$ pkgconf --libs libcares -L/usr/usr/lib64 -lcares
$ pkgconf --libs libasyncns -L/usr/lib -lasyncns
Actually I realise my script doesn't catch this case (32 bit path) since the path exists. I hacked it up to catch this and the complete results are:
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
Rich.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Nov 16, 2022 at 11:35 AM Richard W.M. Jones rjones@redhat.com wrote:
David (CC'd) is working on the Fedora RISC-V port and he noticed that some *.pc files in Fedora contain incorrect paths. For example[1]:
$ pkgconf --libs libcares -L/usr/usr/lib64 -lcares
$ pkgconf --libs libasyncns -L/usr/lib -lasyncns
On non-riscv64 this happens to work because the default search path includes the right directory anyway (eg. /usr/lib64).
On riscv64 this causes build failures since meson seems to go off and search for the *.so files and then tries to construct an absolute path to them (I'm not sure if this isn't a bug in meson TBH). For example:
http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782
This problem appears to be widespread. I scanned just the *-devel packages that I happen to have installed, results below. Not sure how to scan all *-devel packages in Fedora.
What should we do here? Is it worth having an RPM build step that checks for this problem?
Maybe it would make sense to have a brp check for that, so that the builds error out with invalid paths? Similar to e.g. how /usr/lib/rpm/check-rpaths is hooked into %__os_install_post in /usr/lib/rpm/redhat/macros
On Wed, Nov 16, 2022 at 12:14:21PM +0100, Kalev Lember wrote:
On Wed, Nov 16, 2022 at 11:35 AM Richard W.M. Jones rjones@redhat.com wrote:
David (CC'd) is working on the Fedora RISC-V port and he noticed that some *.pc files in Fedora contain incorrect paths. For example[1]: $ pkgconf --libs libcares -L/usr/usr/lib64 -lcares $ pkgconf --libs libasyncns -L/usr/lib -lasyncns On non-riscv64 this happens to work because the default search path includes the right directory anyway (eg. /usr/lib64). On riscv64 this causes build failures since meson seems to go off and search for the *.so files and then tries to construct an absolute path to them (I'm not sure if this isn't a bug in meson TBH). For example: http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782 This problem appears to be widespread. I scanned just the *-devel packages that I happen to have installed, results below. Not sure how to scan all *-devel packages in Fedora. What should we do here? Is it worth having an RPM build step that checks for this problem?Maybe it would make sense to have a brp check for that, so that the builds error out with invalid paths? Similar to e.g. how /usr/lib/rpm/check-rpaths is hooked into %__os_install_post in /usr/lib/rpm/redhat/macros
Yes this is exactly what I was thinking too. I filed a bug to track the work:
https://bugzilla.redhat.com/show_bug.cgi?id=2143244
Rich.
On Wed, Nov 16, 2022 at 10:34:42AM +0000, Richard W.M. Jones wrote:
David (CC'd) is working on the Fedora RISC-V port and he noticed that some *.pc files in Fedora contain incorrect paths. For example[1]:
$ pkgconf --libs libcares -L/usr/usr/lib64 -lcares
$ pkgconf --libs libasyncns -L/usr/lib -lasyncns
On non-riscv64 this happens to work because the default search path includes the right directory anyway (eg. /usr/lib64).
On riscv64 this causes build failures since meson seems to go off and search for the *.so files and then tries to construct an absolute path to them (I'm not sure if this isn't a bug in meson TBH). For example:
http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782
This problem appears to be widespread. I scanned just the *-devel packages that I happen to have installed, results below. Not sure how to scan all *-devel packages in Fedora.
What should we do here? Is it worth having an RPM build step that checks for this problem?
Not only should the directory exist, but I think it should exist in the same RPM that is shipping the .pc file itself. ie the -devel package should contain the pkg-config file, header file(s) and at least 1 unversioned .so file(s) in the directories listed. If any of those are in different sub-RPMs from each other it would indicate a packaging bug as well.
Could be done as an rpmlint check, so it is caught during package review, in addition to doing it in some post build CI process.
With regards, Daniel