[PATCH 0/1] MR1432: configure: Override PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH for 32-bit builds on 64-bit hosts.

[Zebediah Figura (＠zfigura)]

This allows 32-bit packages to be found when the user has specified
PKG_CONFIG_PATH for some other reason.

This also mirrors the way e.g. i686-linux-gnu-pkg-config is implemented on
Debian, and possibly other distributions as well.

This also prevents 64-bit .pc files from being found. This was originally
intended as a benefit [1], but can contribute to misdetection of headers which
are not actually multiarch (e.g. GStreamer, although at the time that [1] was
written that was a preëxisting problem). In general a distribution which
provides .pc files for one architecture should be expected to provide them for
any architecture that it actually provides libraries for; even if that was not
true of Debian in 2017, it is now. I moreover assert it is better to fail to
find a present library than to incorrectly find the wrong one.

Note that we can't easily use i686-linux-gnu-pkg-config, as would otherwise be
preferable, for reasons also described in [1].

[1] https://www.winehq.org/pipermail/wine-devel/2017-June/118002.html

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/1432

[PATCH 1/1] configure: Override PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH for 32-bit builds on 64-bit hosts.

[Zebediah Figura]

From: Zebediah Figura <zfigura(a)codeweavers.com>

This allows 32-bit packages to be found when the user has specified
PKG_CONFIG_PATH for some other reason.

This also mirrors the way e.g. i686-linux-gnu-pkg-config is implemented on
Debian, and possibly other distributions as well.

This also prevents 64-bit .pc files from being found. This was originally
intended as a benefit [1], but can contribute to misdetection of headers which
are not actually multiarch (e.g. GStreamer, although at the time that [1] was
written that was a preëxisting problem). In general a distribution which
provides .pc files for one architecture should be expected to provide them for
any architecture that it actually provides libraries for; even if that was not
true of Debian in 2017, it is now. I moreover assert it is better to fail to
find a present library than to incorrectly find the wrong one.

Note that we can't easily use i686-linux-gnu-pkg-config, as would otherwise be
preferable, for reasons also described in [1].

[1] https://www.winehq.org/pipermail/wine-devel/2017-June/118002.html
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 4e852da5ee7..c15df1090b4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -129,8 +129,8 @@ case $host in
       host_cpu="i386"
       notice_platform="32-bit "
       TARGETFLAGS="$TARGETFLAGS -m32"
-      PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib32/pkgconfig:/usr/lib/pkgconfig}
-      export PKG_CONFIG_PATH
+      PKG_CONFIG_LIBDIR=${PKG_CONFIG_LIBDIR:-/usr/lib/i386-linux-gnu/pkgconfig:/usr/lib32/pkgconfig:/usr/lib/pkgconfig}
+      export PKG_CONFIG_LIBDIR
       with_unwind=${with_unwind:-no}
     else
       if test "x${GCC}" = "xyes"
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/1432