Does not seem to consider PKG_CONFIG_PATH on Windows

[sdroege]

See following output (it's the same with 0.3.9 and latest git of the pkg-config crate). This is with the MinGW target of Rust.

slomo@DESKTOP-63UL5V9 MSYS ~/gstreamer-rs
$ cargo build --all
    Updating git repository `https://github.com/alexcrichton/pkg-config-rs`
   Compiling pkg-config v0.3.9 (https://github.com/alexcrichton/pkg-config-rs#175dd559)
   Compiling glib-sys v0.4.0 (https://github.com/gtk-rs/sys#b08fc0e1)
error: failed to run custom build command for `glib-sys v0.4.0 (https://github.com/gtk-rs/sys#b08fc0e1)`
process didn't exit successfully: `C:\msys64\home\slomo\gstreamer-rs\target\debug\build\glib-sys-7dbb58e7b49d4edd\build-script-build` (exit code: 1)
--- stderr
`"pkg-config" "--libs" "--cflags" "glib-2.0 >= 2.32"` did not exit successfully: exit code: 1
--- stderr
Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found


warning: build failed, waiting for other jobs to finish...
error: build failed

slomo@DESKTOP-63UL5V9 MSYS ~/gstreamer-rs
$ pkg-config --libs --cflags "glib-2.0 >= 2.32"
-mms-bitfields -I/c/gstreamer/1.0/x86_64/include/glib-2.0 -I/c/gstreamer/1.0/x86_64/lib/glib-2.0/include -L/c/gstreamer/1.0/x86_64/lib -lglib-2.0 -lintl -lws2_32 -lole32 -lwinmm -lshlwapi -lintl

slomo@DESKTOP-63UL5V9 MSYS ~/gstreamer-rs
$ echo $PKG_CONFIG_PATH
/c/gstreamer/1.0/x86_64/lib/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig:/lib/pkgconfig

[alexcrichton]

Hm AFAIK this doesn't attempt to change the env var at all, but I wouldn't be too surprised if pkg-config-the-program on MinGW behaved differently when invoked from the shell vs from a "native" windows app like a Rust build script.

[alexcrichton]

Can you try printing out env::var("PKG_CONFIG_PATH") in the associated build script and see what pops out?

[sdroege]

It's indeed behaving different: it's printing the paths as Windows paths (c:\etc) instead of UNIX-style paths. If I set PKG_CONFIG_PATH to such paths myself, pkg-config also fails to find everything.

The pkg-config I have here is the one from msys2.

[alexcrichton]

Hm yeah so I know things are really weird on msys2/mingw sometimes, I just never really know when or why. It sounds like our only recourse here is to detect that we'll be calling msys2 and then munge paths manually, but that's sort of crappy :(

[sdroege]

And not only those, but probably also the paths that pkg-config is returning?

[alexcrichton]

Presumably? It's probably easiest just to give a better error and say "install the mingw versions instead of the msys verisons instead"

[sdroege]

Or that :)

[nirbheek]

I thought I'd clear up some terminology here so that the error message is not confusing.

MinGW is a port of the GNU toolchain to Windows, and it does not include pkg-config or any other tools. This port is basically unmaintained, and everyone uses MinGW-W64, which is a totally independent effort.

For the tools (including pkg-config), MSYS is one distribution which is shipped with both MinGW and MinGW-W64. In my experience this works quite well but can be difficult to setup.

MSYS2 is a totally separate effort from all these and ships its own toolchains (which it also calls 'MinGW', and is based on MinGW-W64) and its own tools. It is a from-scratch rewrite inspired by Cygwin (but does not use Cygwin), and it really easy to setup and use since it uses the pacman package manager.

Unfortunately in my experience MSYS2 ships broken versions of tools (including pkg-config). As long as you only use the MSYS2 environment everything works fine, but as soon as you try to mix with outside toolchains (msvc, rustc, etc) or windows tools you quickly run into edge cases. For instance, MSYS does path translation in the environment and on the command-line which MSYS2 does not.

On the Rust side, it might be useful to have something like Python's pathlib which allows you to translate from Windows to UNIX paths very easily. Then pkg-config-rs would be able to instantiate a PurePath object and convert to UNIX with the equivalent of PurePath.as_posix() to ensure that the right kinds of paths are passed in the env to pkg-config.

[nirbheek]

Also, if you only want pkg-config, maybe you can use https://sourceforge.net/projects/pkgconfiglite/ which is a standalone executable. It has worked well for me, but I have not used it extensively.

Ideally someone would reimplement pkg-config in Rust though ;)

[RazrFalcon]

Is there a workaround for this issue?

[nirbheek]

@RazrFalcon yes, don't use MSYS2's pkg-config. Use pkgconfiglite which is a standalone executable you can drop anywhere in your PATH.

[Eletroboss]

Don't install the pkg-config (pkgconf) package from pacman like so:
$ pacman -S pkg-config (or pkgconf)
These packages are outdated
Instead install the mingw-w64-x86_64-pkg-config package thus:
$ pacman -S mingw-w64-x86_64-pkg-config
This does not have the problem with the environment variable.

[nirbheek]

Yes, @Eletroboss you are correct that the solution is to use mingw-w64-x86_64-pkg-config (or the correct one for your MSYS2 environment). When you install pkg-config or pkgconf, you are actually installing the "msys" variant.

We already had this problem in Meson too: mesonbuild/meson#3653

pkg-config-rs should probably reject this pkg-config / pkgconf.

[sdroege]

Can this variant of pkg-config be easily detected?

[nirbheek]

Yeah, should be easy to detect. Most likely you're running from the wrong environment (easy to detect with env vars) or you are using the wrong pkg-config (easy to detect from the path). Will add it to #165.