in reply to Re^10: 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?

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.

Replies are listed 'Best First'.
Re^12: gmake error on Glib compile
by syphilis (Archbishop) on Aug 25, 2023 at 12:22 UTC
    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
[reply]
[d/l]
[select]

      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.

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

        [download]
        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 https://www.perlmonks.org/?node_id=11154072 and addressed by the patch at https://rt.cpan.org/Ticket/Display.html?id=149570

        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 ;-)

        Cheers,
        Rob
[reply]
[d/l]

In Section Seekers of Perl Wisdom