in reply to Re^7: gmake error on Glib compile
in thread gmake error on Glib compile

FWIW, Font::FreeType builds and passes all tests for me when using SP 5.38.0.1 PDL edition

Yes - my only issue with Font::FreeType is a personal thing I have against Devel::CheckLib.
Devel::CheckLib is a module that's not present on my own perl-5.38.0 build, and I'm averse to installing it.
I updated my previous post to show the Makefile.PL I used to build Font::FreeType.

The main issue is that Glib-Object-Inrospection-0.050 being built on SP-5.38.0 is unusable - whereas the G-O-I-0.050 that I build on my own 5.38.0 works fine.
Having installed it on SP, anyway, the problem is demonstrated by the one-liner I provided at the end of my previous post.

With G-O-I, the test scripts are not generated, and the test suite should just skip all of the test scripts.
But errors that include "Can't load 'C:/sp/_64/sp-5.38.0/perl/site/lib/auto/Glib/Glib.xs.dll' for module Glib: load_file:The specified module could not be found at C:/sp/_64/sp-5.38.0/perl/lib/DynaLoader.pm line 206" are being generated for each test script.
The same thing usually (but not always) happens when I build G-O-I on my own perl ... it's a bit perplexing, but I'll continue to poke at it until that one-liner works on SP.
With my own build of perl, that one-liner always works - which means that the Gtk3 test scripts don't abort, and instead (most of them) pass.

Cheers,
Rob

Replies are listed 'Best First'.
Re^9: gmake error on Glib compile
by swl (Prior) on Aug 25, 2023 at 02:34 UTC

    I'm sure you have good reasons to not like Devel::CheckLib but perhaps FFI::CheckLib would make a good substitute. Maybe it has the same issues, though.

    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? e.g. somelib.dll is in the dependency chain and is provided by both Strawberry Perl and MSYS2 but the wrong one is being picked up.

[reply]
      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]

        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]
[reply]
[d/l]
[select]

        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]

In Section Seekers of Perl Wisdom