I just had a go with the different pkg-config utilities. The difference appears to be that the MSYS2 version prepends the relevant path when run outside of the MSYS2 environment. I guess the pure-perl version could be taught to work with such paths but it's perhaps only an issue because these builds are using mingw64 files?

Windows cmd shell:

C:\path>set PKG_CONFIG_PATH=C:\msys64\mingw64\lib\pkgconfig

C:\path>pkg-config --libs glib-2.0
-L/mingw64/lib -lglib-2.0 -lintl

C:\path>\msys64\mingw64\bin\pkg-config.exe --libs glib-2.0
-LC:/msys64/mingw64/lib -lglib-2.0 -lintl
[download]

MSYS2 mingw64 shell:

$ pkg-config --libs glib-2.0
-lglib-2.0 -lintl
[download]

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

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]

What dependencies are listed when you run objdump on the dll with the error?

The above might need to be applied recursively depending on what DLLs are listed. On my mingw64 system, libgobject leads to libglib, libpcre2, libintl and libiconv.

What dependencies are listed when you run objdump on the dll with the error?

I had used objdump to look at the Glib.xs.dll dependencies, and saw nothing suspicious. But I hadn't recursed to look any deeper.
I probably should have taken the time to point out that this error appears only when the test files are run under Test::Harness.
If I run (eg) perl -Mblib t/00-basic-types.t then, instead of getting that error, I get the result that I expect:

1..0 # SKIP Need the test libraries
[download]

I spent some time (about 5 years ago) trying to get the test libraries to build - but without success. (IIRC, the building of those libraries relied on python. Little surprise to me that python couldn't do that ... and even less concern.)

The good news is that ditching Strawberry's pkg-config.bat in favour of msys2's mingw64/pkg-config.exe has worked a treat.
Not only has it eliminated the need to set CPATH and LIBRARY_PATH environment variables, but Gtk3 is now usable. (Instead of all 22 Gtk3 test scripts crashing, 19 of them now pass all tests - same as with my own perl-5.38.0 build.)

I haven't yet properly dealt with the way that the G-I-O-0.050 test suite misbehaves, but it's looking to me (at the moment) that this misbehaviour is of little consequence,

Cheers,
Rob

Getting it to build is good news.

If you can isolate the differences between pkg-config versions then it's worth logging an issue with PkgConfog.