Skip Menu |

This queue is for tickets about the Glib-Object-Introspection CPAN distribution.

Report information
The Basics
Id: 93385
Status: resolved
Priority: 0/
Queue: Glib-Object-Introspection

People
Owner: Nobody in particular
Requestors: sisyphus [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.020
Fixed in: (no value)



Subject: [Win32] Test libraries fail to build
On Windows, it seems that the intention is to use python (Python-2.7, in my case) to build the test libraries. For Windows, the Makefile.PL has: ############ foreach my $base (map { File::Spec->catfile ($_, 'g-ir-scanner') } @path) { if (-f $base) { $gir_cmd = qq(python $base); $found = 1; last; } } ############ The first problem is that I have no file named 'g-ir-scanner'. I do have a file named 'g-ir-scanner.py' (in C:/usr/local/bin). It shipped with the glib/gobject-introspection binaries against which I'm building G::O::I-0.020. Assuming that's the file we're looking for, I've modified the filename given in the above snippet to include the '.py' extension. The file then gets found, and the python command is executed. Changing $pipe (in the Makefile.PL) to the empty string allows me to see that the python command creates an error: ############ Trying to build test libraries... Traceback (most recent call last): File "C:\usr\local\bin\g-ir-scanner.py", line 43, in <module> from giscanner.scannermain import scanner_main ImportError: No module named giscanner.scannermain not OK ############ Where to from here ? The module does build, but then all of the tests are skipped because there are no test libraries. After installing the G::O::I-0.020, I find it loads ok ... but I'd like to see some tests passing as I'm a little sceptical about the usability of the built module. For one thing, during 'dmake install', I see no mention of any typelibs being installed - yet the documentation suggests that the typelibs (which exist in C:/usr/local/lib/girepository-1.0) should be installed by the module. I'm running mingw.org's port of (32-bit) gcc-4.7.0, and perl-5.16.0 built using that gcc compiler. Cheers, Rob
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Wed, 26 Feb 2014 14:00:33 +0100
To: bug-Glib-Object-Introspection [...] rt.cpan.org
From: "Torsten Schönfeld" <kaffeetisch [...] gmx.de>
"Sisyphus via RT" <bug-Glib-Object-Introspection@rt.cpan.org>: Show quoted text
> The first problem is that I have no file named 'g-ir-scanner'. I do have a file named 'g-ir-scanner.py' (in C:/usr/local/bin). It shipped with the glib/gobject-introspection binaries against which I'm building G::O::I-0.020. Assuming that's the file we're looking for, I've modified the filename given in the above snippet to include the '.py' extension.
Yes, that's probably the correct file. We'd have to make Makefile.PL search for both variants, then. Patches welcome. Show quoted text
> ############ > Trying to build test libraries... Traceback (most recent call last): > File "C:\usr\local\bin\g-ir-scanner.py", line 43, in <module> > from giscanner.scannermain import scanner_main > ImportError: No module named giscanner.scannermain > not OK > ############ > > Where to from here ?
Are you sure that your installation of gobject-introspection is complete? Is there maybe an associated "development" package that you don't have yet? Is Makefile.PL using the same Python interpreter that gobject-introspection is referring to? On my system, the file corresponding to the failing import is at /usr/lib64/gobject-introspection/giscanner/scannermain.py. Show quoted text
> For one thing, during 'dmake install', I see no mention of any typelibs being installed - yet the documentation suggests that the typelibs (which exist in C:/usr/local/lib/girepository-1.0) should be installed by the module.
No, the Perl bindings don't install any typelibs. What part of the docs gave you that impression? Introspectable libraries are supposed to install their typelibs themselves. To test things manually, try to use one of the typelibs that you have installed. For example, if you have Gio-2.0.typelib: use Glib::Object::Introspection; Glib::Object::Introspection->setup( basename => 'Gio', version => '2.0', package => 'Glib::IO'); my $loop = Glib::MainLoop->new (); my $file = Glib::IO::File::new_for_path ($0); $file->query_info_async ('*', [], 0, undef, \&info); sub info { my ($file, $res) = @_; my $info = $file->query_info_finish ($res); warn $info->get_name (); warn $info->get_size (); $loop->quit (); } $loop->run ();
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Fri, 28 Feb 2014 17:07:40 +1100
To: <bug-Glib-Object-Introspection [...] rt.cpan.org>, <sisyphus [...] cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: Torsten Schoenfeld via RT
>> Where to from here ?
> Are you sure that your installation of gobject-introspection is complete?
I *think* it will prove to be complete ... no guarantees about that yet, however.
> Is there maybe an associated "development" package that you don't have > yet?
This looks like a full devel package to me. It's at: https://github.com/tomnotcat/glib-win32/archive/master.zip
> Is Makefile.PL using the same Python interpreter that > gobject-introspection is referring to?
No. The only Python 27 I have is one that I installed independently.
> On my system, the file corresponding to the failing import is at > /usr/lib64/gobject-introspection/giscanner/scannermain.py.
The binaries that I have contain scannermain.py in the C:\usr\local\python27\Lib\giscanner directory. It occurs to me that the Python27 I'm using won't know anything about that location. How does one remedy that ?
>> For one thing, during 'dmake install', I see no mention of any typelibs >> being installed - yet the documentation suggests that the typelibs (which >> exist in C:/usr/local/lib/girepository-1.0) should be installed by the >> module.
> No, the Perl bindings don't install any typelibs. What part of the docs > gave you that impression? Introspectable libraries are supposed to > install their typelibs themselves.
I was looking at this piece of documentation near the beginning of the docs: ############################ DESCRIPTION "Glib::Object::Introspection->setup" To allow Glib::Object::Introspection to create bindings for a library, it must have installed a typelib file, for example "$prefix/lib/girepository-1.0/Gtk-3.0.typelib". ############################ Looks like I might've misread what "it" was applying to. (I thought "it" was Glib::Object::Introspection ....)
> To test things manually, try to use one of the typelibs that you have > installed. For example, if you have Gio-2.0.typelib: > > use Glib::Object::Introspection; > Glib::Object::Introspection->setup( > basename => 'Gio', > version => '2.0', > package => 'Glib::IO'); > > my $loop = Glib::MainLoop->new (); > > my $file = Glib::IO::File::new_for_path ($0); > $file->query_info_async ('*', [], 0, undef, \&info); > sub info { > my ($file, $res) = @_; > > my $info = $file->query_info_finish ($res); > warn $info->get_name (); > warn $info->get_size (); > > $loop->quit (); > } > > $loop->run ();
Running that outputs: ############################## (perl.exe:3040): Glib-GObject-CRITICAL **: ..\..\..\gobject\gtype.c:2722: You forgot to call g_type_init() (perl.exe:3040): Glib-CRITICAL **: file ..\..\..\glib\gthread.c: line 713: assertion `result != 0' failed (perl.exe:3040): Glib-GObject-CRITICAL **: file ..\..\..\gobject\gobject.c: line 1538: assertion `G_TYPE_IS_OBJECT (object_type)' failed [and then hangs at that point] ############################## This is essentially the same as what happens when I try to run any of the Gtk3-0.016 test scripts. I tried adding the following argument to setup() in the above demo: search_path => 'C:/usr/local/lib/girepository-1.0' but this does not change the error. (Btw C:/usr/local/lib/girepository-1.0 contains Gio-2.0.typelib, among other typelib files.) I have tried (and failed) to build the gobject-introspection library myself - hence have resorted to binaries created by someone else. Cheers, Rob
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Fri, 28 Feb 2014 20:32:26 +1100
To: <bug-Glib-Object-Introspection [...] rt.cpan.org>, <sisyphus [...] cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: sisyphus1@optusnet.com.au
> The binaries that I have contain scannermain.py in the > C:\usr\local\python27\Lib\giscanner directory. > It occurs to me that the Python27 I'm using won't know anything about that > location. How does one remedy that ?
I copied the gi and giscanner directories from C:\usr\local\python27\Lib to my Python27/Lib folder (C:/_32/Python27/Lib) and the requisite py files now get found .... and the test libraries now build OK. But, in the G::O::I test suite, I'm still getting slugged with: ############################# t/00-basic-types.t ............ (perl.exe:4416): Glib-GObject-CRITICAL **: ..\..\..\gobject\gtype.c:2722: You forgot to call g_type_init() (perl.exe:4416): Glib-CRITICAL **: file ..\..\..\glib\gthread.c: line 713: assertion `result != 0' failed (perl.exe:4416): Glib-GObject-CRITICAL **: file ..\..\..\gobject\gobject.c: line 1538: assertion `G_TYPE_IS_OBJECT (object_type)' failed [Hang .....] ############################# Any ideas on that ? (I'll see if I can come up with something.) Cheers, Rob
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Sat, 1 Mar 2014 22:39:19 +1100
To: <bug-Glib-Object-Introspection [...] rt.cpan.org>, <sisyphus [...] cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: sisyphus1@optusnet.com.au
> ############################# > t/00-basic-types.t ............ > (perl.exe:4416): Glib-GObject-CRITICAL **: ..\..\..\gobject\gtype.c:2722: > You forgot to call g_type_init() > > (perl.exe:4416): Glib-CRITICAL **: file ..\..\..\glib\gthread.c: line 713: > assertion `result != 0' failed > > (perl.exe:4416): Glib-GObject-CRITICAL **: file > ..\..\..\gobject\gobject.c: line 1538: assertion `G_TYPE_IS_OBJECT > (object_type)' failed > > [Hang .....] > #############################
This apparently arises because I've built my Glib-1.301 (perl module) against a different set of binaries than the ones against which I built G::O::I-0.020. More specifically, I speculate that the problem comes about because my Glib-1.301 and G::O::I-0.020 load different (ie separate and distinct) glib dynamic libraries (dll's). Certainly, if I rebuild Glib-1.301 against the same binaries as I used for G::O::I-0.020, then the problem goes away. Glib-1.301 loads the glib dll it was built for, and G::O::I-0.020 loads the glib dll it was built for - so it's *not* a case of the wrong dll being loaded. Rather, I envisage that the problem arises because one dll receives the g_type_init() call, but the other dll doesn't see that. I am, however, left with the problem that the typelib files are not being found. If I run the script that Torsten provided (which I've named 'try.pl'), then I get: Typelib file for namespace 'Gio', version '2.0' not found at C:/MinGW/perl516/site/lib/Glib/Object/Introspection.pm line 92. If I provide the correct 'search_path' param to setup(), then the script runs correctly, and outputs: try.pl at try.pl line 17. 563 at try.pl line 18. I'm still left to wonder how one sets things up on Windows such that these typelib files get found *without* having to specify search_path. Perhaps that will become clearer to me tomorrow .... enough for tonight :-) Cheers, Rob
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Sun, 2 Mar 2014 15:10:04 +1100
To: <bug-Glib-Object-Introspection [...] rt.cpan.org>, <sisyphus [...] cpan.org>
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----Original Message----- From: sisyphus1@optusnet.com.au
> I am, however, left with the problem that the typelib files are not being > found.
This is fixed with: set GI_TYPELIB_PATH=C:\usr\local\lib\girepository-1.0 Perhaps the G::O::I documentation could mention this. (Googling for 'glib introspection typelib environment' didn't help, but googling for 'introspection typelib environment' did.) Thanks for the help, Torsten. You can probably close this bug report if you wish. Not sure that the assumption that my Glib module would load the same dll as G::O::I is valid - because they are separate perl modules. (FAIRK, it *is* a valid assumption .... I'm just "not sure" about that, that's all ;-) Cheers, Rob
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Fri, 07 Mar 2014 17:49:21 +0100
To: bug-Glib-Object-Introspection [...] rt.cpan.org
From: Torsten Schönfeld <kaffeetisch [...] gmx.de>
"sisyphus1@optusnet.com.au via RT" <bug-Glib-Object-Introspection@rt.cpan.org> writes: Show quoted text
> I was looking at this piece of documentation near the beginning of the docs: > > ############################ > DESCRIPTION > "Glib::Object::Introspection->setup" > To allow Glib::Object::Introspection to create bindings for a library, > it must have installed a typelib file, for example > "$prefix/lib/girepository-1.0/Gtk-3.0.typelib". > ############################
Ah, yeah, that's not entirely clear. Fixed now in git.
Subject: Re: [rt.cpan.org #93385] [Win32] Test libraries fail to build
Date: Fri, 07 Mar 2014 11:19:02 +0100
To: bug-Glib-Object-Introspection [...] rt.cpan.org
From: Torsten Schönfeld <kaffeetisch [...] gmx.de>
"sisyphus1@optusnet.com.au via RT" <bug-Glib-Object-Introspection@rt.cpan.org> writes: Show quoted text
>> I am, however, left with the problem that the typelib files are not being >> found.
> > This is fixed with: > set GI_TYPELIB_PATH=C:\usr\local\lib\girepository-1.0 > > Perhaps the G::O::I documentation could mention this.
Now done in git. Show quoted text
> Not sure that the assumption that my Glib module would load the same dll as > G::O::I is valid - because they are separate perl modules. > (FAIRK, it *is* a valid assumption .... I'm just "not sure" about that, > that's all ;-)
Not sure I understand you here. Both, Glib and Glib::Object::Introspection must be built against and use the same libglib to avoid problems like the one you encountered. Perl's (or rather, ExtUtils::MakeMaker's) linker calls should automatically ensure that the modules use the libglib at runtime that they were linked against.