Unix-style paths instead of Windows paths are returned under MinGW #234

New Issue

ariadne · 2021-09-14T23:31:38Z

lidavidm commented

2021-09-14 23:31:38 +00:00

(Migrated from github.com)

I noticed behavior of pkgconf changed from v1.7.4 to v1.8.0. Note that v1.7.4 is from MinGW and hence had patches, so I am not quite comparing to upstream pkgconf here: 4861bb970c (diff-dca92e4684e4c4dd39b987eaf87183441672fc566aa0f9be737114dc04b35048)

The environment is MinGW64, installed via msys; the v1.7.4 package was built via the msys PKGBUILD, while the v1.8.0 package here comes from their repos.

In the (patched) v1.7.4, pkgconf gave Windows-style paths:

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ pkg-config --version
1.7.4

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=includedir
C:/msys64/mingw64/include

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=libdir
C:/msys64/mingw64/lib

However, in v1.8.0, it gives Unix-style paths:

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ pkg-config --version
1.8.0

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=includedir
/mingw64/include

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=libdir
/mingw64/lib

When used with MinGW CMake, this causes builds to fail (as CMake apparently does not remap the Unix-style paths to Windows ones).

The .pc file is as follows:

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ cat /mingw64/lib/pkgconfig/liblz4.pc
#   LZ4 - Fast LZ compression algorithm
#   Copyright (C) 2011-2014, Yann Collet.
#   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

prefix=/mingw64
libdir=/mingw64/lib
includedir=/mingw64/include

Name: lz4
Description: extremely fast lossless compression algorithm library
URL: http://www.lz4.org/
Version: 1.9.3
Libs: -L/mingw64/lib -llz4
Cflags: -I/mingw64/include

Note that a slightly different .pc file gives Windows-style paths still, so perhaps this should be fixed by adjusting the .pc file? (Apologies, I am not all that familiar with pkgconf.)

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ cat /mingw64/lib/pkgconfig/libzstd.pc
#   ZSTD - standard compression algorithm
#   Copyright (C) 2014-2016, Yann Collet, Facebook
#   BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php)

prefix=/mingw64
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: zstd
Description: fast lossless compression algorithm library
URL: http://www.zstd.net/
Version: 1.5.0
Libs: -L${libdir} -lzstd
Cflags: -I${includedir}

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config libzstd --variable=includedir
C:/msys64/mingw64/include

User@WinDev2108Eval MINGW64 ~/arrow/foo/build
$ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config libzstd --variable=libdir
C:/msys64/mingw64/lib

Please let me know if this should be reported elsewhere; I'm not sure if this is quite a pkgconf issue, or if the .pc file itself is wrong (in which case it should be fixed in MSYS/lz4).

I noticed behavior of pkgconf changed from v1.7.4 to v1.8.0. Note that v1.7.4 is from MinGW and hence had patches, so I am not quite comparing to upstream pkgconf here: https://github.com/msys2/MINGW-packages/commit/4861bb970cb99879939033fe9cfbcfc841d49402#diff-dca92e4684e4c4dd39b987eaf87183441672fc566aa0f9be737114dc04b35048 The environment is MinGW64, installed via msys; the v1.7.4 package was built via the msys PKGBUILD, while the v1.8.0 package here comes from their repos. In the (patched) v1.7.4, pkgconf gave Windows-style paths: ``` User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ pkg-config --version 1.7.4 User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=includedir C:/msys64/mingw64/include User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=libdir C:/msys64/mingw64/lib ``` However, in v1.8.0, it gives Unix-style paths: ``` User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ pkg-config --version 1.8.0 User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=includedir /mingw64/include User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config liblz4 --variable=libdir /mingw64/lib ``` When used with MinGW CMake, this causes builds to fail (as CMake apparently does not remap the Unix-style paths to Windows ones). The .pc file is as follows: ``` User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ cat /mingw64/lib/pkgconfig/liblz4.pc # LZ4 - Fast LZ compression algorithm # Copyright (C) 2011-2014, Yann Collet. # BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php) prefix=/mingw64 libdir=/mingw64/lib includedir=/mingw64/include Name: lz4 Description: extremely fast lossless compression algorithm library URL: http://www.lz4.org/ Version: 1.9.3 Libs: -L/mingw64/lib -llz4 Cflags: -I/mingw64/include ``` Note that a slightly different .pc file gives Windows-style paths still, so perhaps this should be fixed by adjusting the .pc file? (Apologies, I am not all that familiar with pkgconf.) ``` User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ cat /mingw64/lib/pkgconfig/libzstd.pc # ZSTD - standard compression algorithm # Copyright (C) 2014-2016, Yann Collet, Facebook # BSD 2-Clause License (http://www.opensource.org/licenses/bsd-license.php) prefix=/mingw64 exec_prefix=${prefix} includedir=${prefix}/include libdir=${exec_prefix}/lib Name: zstd Description: fast lossless compression algorithm library URL: http://www.zstd.net/ Version: 1.5.0 Libs: -L${libdir} -lzstd Cflags: -I${includedir} User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config libzstd --variable=includedir C:/msys64/mingw64/include User@WinDev2108Eval MINGW64 ~/arrow/foo/build $ env PKG_CONFIG_PATH=/mingw64/lib/pkgconfig pkg-config libzstd --variable=libdir C:/msys64/mingw64/lib ``` Please let me know if this should be reported elsewhere; I'm not sure if this is quite a pkgconf issue, or if the .pc file itself is wrong (in which case it should be fixed in MSYS/lz4).

lazka commented

2021-09-16 07:21:45 +00:00

(Migrated from github.com)

See downstream issue: https://github.com/msys2/MINGW-packages/issues/9602

I've bisected this regression to 13fe4c8c58 and can confirm that reverting it fixes things (and have done so here https://github.com/msys2/MINGW-packages/pull/9604)

For some reason it breaks the following workaround: ceece2c195/libpkgconf/pkg.c (L296) I haven't looked into it though.

here is an example .pc file affected:

prefix=/mingw64
libdir=/mingw64/lib
includedir=/mingw64/include

Name: poppler-qt5
Description: Qt5 bindings for poppler
Version: 21.08.0
Requires:
Requires.private: poppler = 21.08.0

Libs: -L${libdir} -lpoppler-qt5
Cflags: -I${includedir}/poppler/qt5

See downstream issue: https://github.com/msys2/MINGW-packages/issues/9602 I've bisected this regression to 13fe4c8c589be99b12d and can confirm that reverting it fixes things (and have done so here https://github.com/msys2/MINGW-packages/pull/9604) For some reason it breaks the following workaround: https://github.com/pkgconf/pkgconf/blob/ceece2c19520beaa495708f59d467f840d8477d3/libpkgconf/pkg.c#L296 I haven't looked into it though. here is an example .pc file affected: ``` prefix=/mingw64 libdir=/mingw64/lib includedir=/mingw64/include Name: poppler-qt5 Description: Qt5 bindings for poppler Version: 21.08.0 Requires: Requires.private: poppler = 21.08.0 Libs: -L${libdir} -lpoppler-qt5 Cflags: -I${includedir}/poppler/qt5 ```

lazka commented

2021-09-16 17:46:39 +00:00

(Migrated from github.com)

(The commit causing the change is now reverted in the MSYS2 package)

👍 2

lidavidm commented

2021-09-16 18:32:18 +00:00

(Migrated from github.com)

Thanks for looking at this!

ariadne commented

2021-10-06 17:33:33 +00:00

@midipix can you provide some commentary here?

midipix commented

2021-10-06 17:59:44 +00:00

(Migrated from github.com)

At a glance: while commit 13fe4c8 fixed a real problem and seems to be sufficient on unix-like systems, it might need to be refined for mingw (and possibly also msys).

In my humble opinion, and given prefix=/mingw64 in the .pc file, pkgconf still does the right thing. On systems where C:/msys64/mingw64 is desired, then either the package could be configured with --prefix=C:/msys64/mingw64, or pkgconf could be asked on the command-line (or configured) to add the C:/msys64 prefix.

Based on irc discussions from back then, I believe that 13fe4c8 reflects a correct understanding of the --define-prefix semantics, yet perhaps with an oversight as far as mingw is concerned.

At a glance: while commit 13fe4c8 fixed a real problem and seems to be sufficient on unix-like systems, it might need to be refined for mingw (and possibly also msys). In my humble opinion, and given `prefix=/mingw64` in the .pc file, pkgconf still does the right thing. On systems where C:/msys64/mingw64 is desired, then either the package could be configured with --prefix=C:/msys64/mingw64, or pkgconf could be asked on the command-line (or configured) to add the C:/msys64 prefix. Based on irc discussions from back then, I believe that 13fe4c8 reflects a correct understanding of the --define-prefix semantics, yet perhaps with an oversight as far as mingw is concerned.

mati865 commented

2021-10-16 12:43:15 +00:00

(Migrated from github.com)

Hardcoding full prefix doesn't work because MSYS2 can be put anywhere user wants to.

Sign in to join this conversation.