[Win32] Glib-Object-Intropsection-0.042

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Win32] Glib-Object-Intropsection-0.042

sisyphus1
Hi,

Firstly, during the Makefile.PL stage, the building of the test libraries
proceeds with all useful output suppressed. (Not very amusing when that
building fails.)
Why is that suppression the default ? ... and how do I turn it off ?

The test libraries don't build because the following command fails:

python
C:\_64\msys64\mingw32\bin\g-ir-scanner --include=cairo-1.0 --include=Gio-2.0
 --namespace=Regress --nsversion=1.0 --quiet --warn-all --warn-error --library=libregress
 --output=Regress-1.0.gir
C:/_64/msys64/mingw32/share/gobject-introspection-1.0/tests/regress.h
C:/_64/msys64/mingw32/share/gobject-introspection-1.0/tests/regress.c 1>NUL
2>NUL

By removing the "1>NUL 2>NUL" at the end of that command, I get to see this
following piece of information:

ERROR: can't resolve libraries to shared libraries: libregress

But that's all I've so far managed to reveal.
libregress.dll exists in the Glib-Object-Intropsection-0.042/build directory

Beyond that, the build of the module also fails with unresolved symbols.

I was able to work around that by providing the full linking list on the
command line:

perl Makefile.PL
LIBS="-LC:\MinGW\perl524_64int\site\lib\auto\Glib -lGlib -LC:\_64\msys64\mingw32\lib
 -lgirepository-1.0 -lgobject-2.0 -lgio-2.0 -lglib-2.0 -lintl -lgmodule-2.0  
-lffi -lgthread-2.0"
make
make test
make install

That all works fine but 'make test', of course, runs no tests because the
test libraries didn't build.

The unresolved symbols arose because the link to -lgio-2.0 was missing.
Interestingly, although the link to libgio-2.0.dll.a is missing when it
comes to building G-O-I-0.042 itself, it's present in the command that
(IIUC) successfully built build/libregress.dll.

Any thoughts on how I might coax the test libraries into existence ?
What does the error emitted by the python command tell us ? (I don't know
python at all.)

As regards perl itself, the version is 5.24.0 and archname is
'MSWin32-x86-multi-thread-64int'.

Cheers,
Rob


_______________________________________________
gtk-perl-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: [Win32] Glib-Object-Intropsection-0.042

sisyphus1
-----Original Message-----
From: [hidden email]
Sent: Sunday, March 19, 2017 1:03 PM
To: [hidden email]
Subject: [Win32] Glib-Object-Intropsection-0.042

> Hi,
>
> Firstly, during the Makefile.PL stage, the building of the test libraries
> proceeds with all useful output suppressed. (Not very amusing when that
> building fails.)
> Why is that suppression the default ? ... and how do I turn it off ?
>
> The test libraries don't build because the following command fails:
>
> python
> C:\_64\msys64\mingw32\bin\g-ir-scanner --include=cairo-1.0 --include=Gio-2.0
>   --namespace=Regress --nsversion=1.0 --quiet --warn-all --warn-error --library=libregress
>   --output=Regress-1.0.gir
> C:/_64/msys64/mingw32/share/gobject-introspection-1.0/tests/regress.h
C:/_64/msys64/mingw32/share/gobject-introspection-1.0/tests/regress.c 1>NUL
2>NUL

>
> By removing the "1>NUL 2>NUL" at the end of that command, I get to see
> this following piece of information:
>
> ERROR: can't resolve libraries to shared libraries: libregress
>
> But that's all I've so far managed to reveal.
> libregress.dll exists in the Glib-Object-Intropsection-0.042/build
> directory
>
> Beyond that, the build of the module also fails with unresolved symbols.
>
> I was able to work around that by providing the full linking list on the
> command line:
>
> perl Makefile.PL
> LIBS="-LC:\MinGW\perl524_64int\site\lib\auto\Glib -lGlib -LC:\_64\msys64\mingw32\lib
>   -lgirepository-1.0 -lgobject-2.0 -lgio-2.0 -lglib-2.0 -lintl -lgmodule-2.0
>  -lffi -lgthread-2.0"
> make
> make test
> make install
>
> That all works fine but 'make test', of course, runs no tests because the
> test libraries didn't build.
>
> The unresolved symbols arose because the link to -lgio-2.0 was missing.
> Interestingly, although the link to libgio-2.0.dll.a is missing when it
> comes to building G-O-I-0.042 itself, it's present in the command that
> (IIUC) successfully built build/libregress.dll.
>
> Any thoughts on how I might coax the test libraries into existence ?
> What does the error emitted by the python command tell us ? (I don't know
> python at all.)
>
> As regards perl itself, the version is 5.24.0 and archname is
> 'MSWin32-x86-multi-thread-64int'.
>
> Cheers,
> Rob

I forgot to mention that, having installed Glib-Object-Intropsection-0.042
(even though the test libraries had not been built), I then get the
following disconcerting output if I require() the module:

C:\>perl -le "require Glib::Object::Introspection; print 'loaded';"
Too late to run INIT block at
C:/MinGW/perl524_64int/site/lib/Glib/Object/Introspection.pm line 257.
loaded

Is there an issue in that ?

Cheers,
Rob



_______________________________________________
gtk-perl-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: [Win32] Glib-Object-Intropsection-0.042

sisyphus1
In reply to this post by sisyphus1
-----Original Message-----
From: [hidden email]

[snip]

> Beyond that, the build of the module also fails with unresolved symbols.
>
> I was able to work around that by providing the full linking list on the
> command line:
>
> perl Makefile.PL
> LIBS="-LC:\MinGW\perl524_64int\site\lib\auto\Glib -lGlib -LC:\_64\msys64\mingw32\lib
>  -lgirepository-1.0 -lgobject-2.0 -lgio-2.0 -lglib-2.0 -lintl -lgmodule-2.0
>  -lffi -lgthread-2.0"
> make
> make test
> make install

Actually, while that did "fix" the problem, it wasn't the way to do it.

MSYS2 provides both ".a" (static) and ".dll.a" (import) libraries for most,
if not all, of the gtk3 libraries.

My build was trying was linking to some of the static libraries.
When I hid those static libraries, the build succeeded straight out of the
box - except that the test libraries did not build because of the error I
reported earlier.

Cheers,
Rob

_______________________________________________
gtk-perl-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-perl-list