Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^12: gmake error on Glib compile

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

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

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,


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

    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.

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

      Yes, I'll try to reach an understanding of that and file an issue.

      It would also be nice to not have to rename the Gtk static and import libs.
      UPDATE:One way is to edit the Libs entry in the relevant pc file.
      For example, in D:\msys64\mingw64\lib\pkgconfig\glib-2.0.pc change the entry:
      Libs: -L${libdir} -lglib-2.0 -lintl to Libs: -L${libdir} -lglib-2.0.dll -lintl.dll
      That's probably less tedious than renaming the libraries, but it's still tedious :-(

      And it would be good to not have to edit any of the generated Makefiles.
      UPDATE: This is achieved by downgrading ExtUtils-Depends-0.8001 to ExtUtils-Depends-0.8000.

      Finally, I'd like to see the G-I-O-0.050 test suite skip all of the tests as it should. (I actually managed to get that to happen a coupla nights back with my own build of perl-5.38.0 ... but haven't since been able to reproduce that "success".)
      UPDATE: This is discussed at and addressed by the patch at

      Unfortunately, there's a lot of opacity to get through when dealing with each of those issues ... but I'll plug away at it, at least util I get sick of it ;-)


        Hi sorry but i have been a way for a while and came back to this today. Good news is GLIB now installed, but getting similar undefined reference to in Cairo now even though i have renamed the dlls etc.

        C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x8 +6_64-w64-mingw32/bin/ld.exe: C:\msys64\mingw64\lib\libcairo.a(win32_c +airo-win32-printing-surface.c.obj):(.text+0x3fbc): more undefined ref +erences to `__stack_chk_fail' follow collect2.exe: error: ld returned 1 exit status gmake: *** [Makefile:522: blib\arch\auto\Cairo\Cairo.xs.dll] Error 1

        Thanks Mike