Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^10: gmake error on Glib compile

by syphilis (Archbishop)
on Aug 25, 2023 at 03:17 UTC ( [id://11154033] : note . print w/replies, xml ) Need Help??


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

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

Replies are listed 'Best First'.
Re^11: gmake error on Glib compile
by swl (Parson) on Aug 25, 2023 at 04:58 UTC

    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.

      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

        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.

Re^11: gmake error on Glib compile
by swl (Parson) on Sep 05, 2023 at 03:33 UTC

    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

    MSYS2 mingw64 shell:

    $ pkg-config --libs glib-2.0 -lglib-2.0 -lintl
      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