But to bring things back to the main thread and the second comment in my previous post, is it possible the dependencies have a clash somewhere?
Sorry - I did think about that (and will continue to keep it in mind), but then neglected to respond to it.
I suspect (haven't checked) that both MSYS2 and SP provide a freetype2 library - but then there are no problems with freetype, anyway.
Also, I think such problems would result in some noise about missing entry points or somesuch.
As regards the Gtk2 stuff, those libraries exist only in MSYS2 - so I don't think that dll nameclashes could be part of the problem with G-O-I.
I've just noticed that, with my own build of 5.38.0, pkg-config version 0.29.2 is being used, whereas SP is using version 0.26 (in the form of Strawberry's perl/bin/pkg-config.bat).
So, tonight, I'll rebuild the Gtk2 stuff on SP using the 0.29.2 version, and see if that makes any difference.
With SP builds, I've needed to specify CPATH and LIBRARY_PATH for the Gtk2 headers and libraries to be found. And that, in itself, suggests to me that the pkg-config.bat being used is not quite doing the job correctly.
Please do keep any suggestions/ideas coming in. I'm just bumping around in the dark ;-)
Cheers,
Rob | [reply] |
What dependencies are listed when you run objdump on the dll with the error?
objdump -x C:\sp\_64\sp-5.38.0\perl\site\lib\auto\Glib\Glib.xs.dll | findstr /C:"DLL Name"
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.
| [reply]
[d/l] |
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
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 | [reply]
[d/l]
[select] |
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
MSYS2 mingw64 shell:
$ pkg-config --libs glib-2.0
-lglib-2.0 -lintl
| [reply]
[d/l]
[select] |
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
| [reply] |
