Re^12: gmake error on Glib compile

The difference appears to be that the MSYS2 version prepends the relevant path when run outside of the MSYS2 environment

I found that if the "${prefix}" in the pc files is replaced with the actual (hard coded) directory, then Strawberry's pkg-config.bat worked fine.
IOW, I think you're right - and I think it's because pkg-config.bat doesn't understand "${prefix}" like MSYS2 does.

I had originally set CPATH and LIBRARY_PATH environment variables to point to the relevant headers and libs when building with pkg-config.bat.
I think that worked because it then meant that pkg-config.bat did not have to locate those files. (They just automatically get found anyway.)

Cheers,
Rob

Comment on Re^12: gmake error on Glib compile

Replies are listed 'Best First'.
Re^13: gmake error on Glib compile by swl (Prior) on Sep 05, 2023 at 22:37 UTC
I think it's because pkg-config.bat doesn't understand "${prefix}" like MSYS2 does. It's not so much that the pure perl pkg-config does not understand `${prefix}`. It's more that it does not correct for the MSYS2 paths. The mingw64 glib-2.0.pc file is below. The prefix is set to a location that only MSYS2 knows how to convert to a "normal" windows path. If the prefix is set to `prefix=${pcfiledir}/../..` then the issue might disappear. FWIW, this approach is used for all but one of the .pc files under strawberry perl 5.38 (that file being zlib.pc). `prefix=/mingw64 includedir=${prefix}/include libdir=${prefix}/lib bindir=${prefix}/bin glib_genmarshal=${bindir}/glib-genmarshal gobject_query=${bindir}/gobject-query glib_mkenums=${bindir}/glib-mkenums Name: GLib Description: C Utility Library Version: 2.76.4 Requires.private: libpcre2-8 >= 10.32 Libs: -L${libdir} -lglib-2.0 -lintl Libs.private: -lws2_32 -lole32 -lwinmm -lshlwapi -luuid -lm Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include` [download]	[reply] [d/l] [select]
Re^14: gmake error on Glib compile by syphilis (Archbishop) on Sep 06, 2023 at 00:29 UTC
The prefix is set to a location that only MSYS2 knows how to convert to a "normal" windows path. Yes - that nails it nicely as "the clear, concise and accurate explanation". Cheers, Rob	[reply]