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

The poorer result for the Gtk2-1.24993 tests that I get with Strawberry Perl is entirely due to the fact that perl/site/lib/Gtk2/Gdk/Keysyms.pm is generated as an empty file on Strawberry.
When I replace that empty file with the correctly generated Keysyms.pm that my own build of perl-5.38.0 created, then I get identical results of "5/227 failing test programs", not "11/227 failing test programs.
I tried to put the contents of that Keysyms.pm on my scratchpad, but it's too big for perlmonks to accommodate.
If anyone wants a copy of it just /msg me with an email address I can post it to.

I don't know why Strawberry doesn't provide the same Keysyms.pm. (I've got some notes on my Windows 7 machine from 5 years ago that inform me that the same thing happened back then, too.)

I've also got some old notes stating that installing Font::FreeType improves the capabilities of Cairo.
I was going to try that out, but Devel::CheckLib is a prereq, and I'm not up to dealing with that annoying hoop tonight.

<UPDATE>
I've now (approx 24 hours later) built and installed Font-FreeType-0.16. It builds and tests fine, but doesn't change anything AFAICS. To build Font-FreeType, I replaced the Makefile.PL that ships with the distro with: 
use strict;
use warnings;
use ExtUtils::MakeMaker;

WriteMakefile(
    NAME               => 'Font::FreeType',
    AUTHOR             => 'Geoff Richards <qef@laxan.com>',
    VERSION_FROM       => 'lib/Font/FreeType.pm',
    LIBS => '-LD:/msys64/mingw64/lib -lfreetype',
    INC  => '-ID:/msys64/mingw64/include/freetype2',
);

[download]
</UPDATE>

I've yet to work out why Gtk3 is so broken on the Strawberry build.
The (fairly fundamental) problem is that the following runs fine on my own build of perl-5.38.0: 
D:\>perl -MGtk3 -wle "my ($success, $rest) = Glib::Object::Introspecti
+on->invoke ('Gtk', undef, 'init_check', [$0, @ARGV]); print 'ok';"
ok

[download]
But on Strawberry's 5.38.0, running the same command, I get: 
D:\>perl -MGtk3 -wle "my ($success, $rest) = Glib::Object::Introspecti
+on->invoke ('Gtk', undef, 'init_check', [$0, @ARGV]); print 'ok'"
Could not prepare a call interface at -e line 1.

[download]
Looks like the problem lies with the Glib-Object-Introspection module.

Cheers,
Rob

Replies are listed 'Best First'.
Re^7: gmake error on Glib compile
by swl (Prior) on Aug 24, 2023 at 23:19 UTC

    FWIW, Font::FreeType builds and passes all tests for me when using SP 5.38.0.1 PDL edition. (Edit - and also the non_PDL edition).

    Is this perhaps a clash between the SP DLLs and the MSYS2 DLLs?

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

        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]

In Section Seekers of Perl Wisdom