RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1975416 - new pkg-config impl breaks usage by re-writing paths to add a bogus directory prefix
Summary: new pkg-config impl breaks usage by re-writing paths to add a bogus directory...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: pkgconf
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: beta
: ---
Assignee: Richard W.M. Jones
QA Contact: Tomas Pelka
URL:
Whiteboard:
Depends On: 1974883
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-23 15:58 UTC by Richard W.M. Jones
Modified: 2023-05-09 10:17 UTC (History)
14 users (show)

Fixed In Version: pkgconf-1.7.3-10.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1974883
Environment:
Last Closed: 2023-05-09 08:15:15 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-86389 0 None None None 2022-11-22 08:57:12 UTC
Red Hat Product Errata RHBA-2023:2468 0 None None None 2023-05-09 08:15:17 UTC

Description Richard W.M. Jones 2021-06-23 15:58:17 UTC 
TL;DR is that we recently updated mingw-filesystem in Fedora
and RHEL 9 so that it uses the system pkgconf.  However this
managed to break a use-case (see details below).  We have fixed
this in Fedora (in pkgconf) and now we need the same fix in
RHEL 9.

+++ This bug was initially created as a clone of Bug #1974883 +++

Description of problem:

The new mingw32-filesystem-119-1.fc35.noarch build has caused a regression in pkg-config, resulting in mangled paths being reported which cause builds to fail


I have done a cross compiled mingw32 build of libvirt, installing it into a scratch directory

$ export SCRATCH_DIR="/tmp/scratch"
$ export VROOT="$SCRATCH_DIR/vroot"
$ export LIBDIR="$VROOT/lib"
$ meson build -Ddriver_libvirtd=disabled "--prefix=$VROOT" "--libdir=$LIBDIR" 
$ ninja -C build install

I can see the .pc file correctly poiints the the install location:

$ cat /tmp/scratch/vroot/lib/pkgconfig/libvirt.pc 
prefix=/tmp/scratch/vroot
exec_prefix=/tmp/scratch/vroot
libdir=/tmp/scratch/vroot/lib
includedir=/tmp/scratch/vroot/include
datarootdir=/tmp/scratch/vroot/share

libvirt_api=/tmp/scratch/vroot/share/libvirt/api/libvirt-api.xml

# For compat with older versions - also present
# in libvirt-qemu.pc / libvirt-lxc.pc
libvirt_qemu_api=/tmp/scratch/vroot/share/libvirt/api/libvirt-qemu-api.xml
libvirt_lxc_api=/tmp/scratch/vroot/share/libvirt/api/libvirt-lxc-api.xml

Name: libvirt
Version: 7.5.0
Description: libvirt library
Requires:
Libs: -L${libdir} -lvirt
Cflags: -I${includedir}


The vroot also contains my mingw dlls:

$ ls /tmp/scratch/vroot/lib
libvirt-admin.dll.a  libvirt.dll.a  libvirt-lxc.dll.a  libvirt-qemu.dll.a  pkgconfig


The PKG_CONFIG_PATH is set to include this custom install location

export PKG_CONFIG_PATH="$LIBDIR/pkgconfig"

and now I query libvirt:

# i686-w64-mingw32-pkg-config --libs --cflags libvirt
-I/usr/i686-w64-mingw32/sys-root/mingw/tmp/scratch/vroot/include -L/usr/i686-w64-mingw32/sys-root/mingw/tmp/scratch/vroot/lib -lvirt 


We can see that i686-w64-mingw32-pkg-config has decided to arbitrarily add extra directory components onto the paths specified in the .pc file


Reverting back down to mingw32-filesystem-118-1.fc35.noarch fixes the problem so   i686-w64-mingw32-pkg-config actually honours the paths in the .pc file I provide


# i686-w64-mingw32-pkg-config --libs --cflags libvirt
-I/tmp/scratch/vroot/include -L/tmp/scratch/vroot/lib -lvirt 


Version-Release number of selected component (if applicable):
mingw32-filesystem-119-1.fc35.noarch

How reproducible:
Always

Steps to Reproduce:
1. Do a mingw32 build installing with an arbitrary custom prefix eg. $HOME/mingw32-vroot or whatever - any directory not under the mingw system location of /usr/i686-w64-mingw32/sys-root 
2.
3.

Actual results:
i686-w64-mingw32-pkg-config prefixes all paths from the .pc file, with the system path /usr/i686-w64-mingw32/sys-root 

Expected results:
i686-w64-mingw32-pkg-config should provide the paths *exactly* as listed in the .pc files with no modification.

Additional info:

--- Additional comment from Richard W.M. Jones on 2021-06-22 17:51:04 UTC ---

FYI change was this one: https://src.fedoraproject.org/rpms/mingw-filesystem/pull-request/7

--- Additional comment from Sandro Mani on 2021-06-22 22:28:58 UTC ---

This is https://github.com/pkgconf/pkgconf/issues/213

--- Additional comment from Daniel Berrangé on 2021-06-23 08:35:18 UTC ---

Urgh. So current pkgconf release is known to be seriously broken, and there's no sign of any patches for that bug for 4  months.  IMHO we need to either revert this change in mingw-filesystem, or figure out a workaround to fix it until pkgconf upstream deals with it properly.

Note this is blocking libvirt CI for mingw currently, since we rely on being able to install stuff into non-system root prefixes.

--- Additional comment from Sandro Mani on 2021-06-23 12:11:55 UTC ---

Gave it a shot in [1], and proposed upstream [2], let's see what the feedback is.

[1] https://src.fedoraproject.org/rpms/pkgconf/pull-request/3
[2] https://github.com/pkgconf/pkgconf/pull/226

--- Additional comment from Sandro Mani on 2021-06-23 15:52:18 UTC ---

Fixed in pkgconf-1.7.4-2.fc35.
Comment 2 Richard W.M. Jones 2021-10-07 10:18:09 UTC 
https://gitlab.com/redhat/centos-stream/rpms/pkgconf/-/merge_requests/2

Do we have an easy way to test this?  I was only able to check
that the patch cherry picks and doesn't break the build but
I don't see an easy test that the issue is fixed.

Also we're going to need QE ACK and presumably they'll want
to ask the same question.
Comment 3 Ken Dreyer (Red Hat) 2022-09-09 18:26:48 UTC 
I hit this bug when building bundled openssl+libcurl for the Ceph Windows client for RHEL 9. The patch at https://gitlab.com/redhat/centos-stream/rpms/pkgconf/-/merge_requests/2 fixes it for me.

To reproduce the bug, run pkg-config with a package that exists outside mingw's sys-root.

Steps to reproduce:
1. Choose any package that installs libraries, headers, and .pc files. I used openssl.
2. Build and install that package with a --prefix that points outside MinGW's sysroot (/usr/x86_64-w64-mingw32/sys-root/mingw). I used "--prefix /opt/ceph/build.deps/mingw/openssl".
3. Your /opt/ceph/build.deps/mingw/openssl/lib/pkgconfig/libcrypto.pc file should look like this:

prefix=/opt/ceph/build.deps/mingw/openssl
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
enginesdir=${libdir}/engines-1_1

Name: OpenSSL-libcrypto
Description: OpenSSL cryptography library
Version: 1.1.1c
Libs: -L${libdir} -lcrypto
Libs.private: -lws2_32 -lgdi32 -lcrypt32 
Cflags: -I${includedir}

4. Now run "pkg-config --cflags" or "--libs" with this .pc file. For example:

    PKG_CONFIG_LIBDIR="/opt/ceph/build.deps/mingw/openssl/lib/pkgconfig" /usr/bin/x86_64-w64-mingw32-pkg-config --cflags libcrypto

  or

    PKG_CONFIG_LIBDIR="/opt/ceph/build.deps/mingw/openssl/lib/pkgconfig" /usr/bin/x86_64-w64-mingw32-pkg-config --libs libcrypto

Actual results:
pkg-config prepends mingw's sys-root to the paths. These directories do not exist.

  -I/usr/x86_64-w64-mingw32/sys-root/mingw/opt/ceph/build.deps/mingw/openssl/include
  -L/usr/x86_64-w64-mingw32/sys-root/mingw/root/ceph/build.deps/mingw/openssl/lib

(... so my curl build will fail to find openssl for linking.)

Expected results:
pkg-config prints the correct paths:
  -I/opt/ceph/build.deps/mingw/openssl/include 
  -L/root/ceph/build.deps/mingw/openssl/lib -lcrypto 

(and curl successfully cross-compiles with mingw.)
Comment 4 Richard W.M. Jones 2022-09-20 08:40:42 UTC 
Hi, could you consider QE ACK of this bug?  It's a simple backport
and has been tested for nearly a year in Fedora.  From the QE point
of view it's probably sufficient to ensure that the patch is applied
and that's the only testing needed.
Comment 8 Ken Dreyer (Red Hat) 2022-09-30 19:26:25 UTC 
To resolve our specific issue in Ceph, we removed our Windows libcurl dependency in https://github.com/ceph/ceph/pull/48148 .

This bug still occurs for any users who are cross-compiling with pkgconfig, but Ceph no longer does that.
Comment 11 errata-xmlrpc 2023-05-09 08:15:15 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (pkgconf bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2468
Note You need to log in before you can comment on or make changes to this bug.