Bad paths in *.pc (pkgconf) files

[Richard W.M. Jones]

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...

[Richard W.M. Jones]

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.

[Ben Beasley]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Kalev Lember]

On Wed, Nov 16, 2022 at 11:35 AM 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?

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

[Vitaly Zaitsev]

On 16/11/2022 12:14, Kalev Lember wrote:
> Maybe it would make sense to have a brp check for that, so that the 
> builds error out with invalid paths?

+1. Such a check would be very helpful.

[Richard W.M. Jones]

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  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.

[Daniel P. Berrangé]

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