so I will download Strawberry 32 bit this weekend and start from the beginning
The G::O::I build should then work for you, using the binaries you already have.
Just make sure you use those same binaries to build the Glib module (which is a pre-requisite for G::O::I). I was using a Glib module that had been built against different binaries - when I rebuilt Glib-1.301 against the same binaries most of my problems with G::O::I disappeared.
The only problem I now have (afaik) is that the typelib files are not being found by default, and I have to use the search_path option (mentioned near the beginning of the G::O::I docs) in order that they are found.
Of course, the test suites for both G::O::I and Gtk assume that the typelib files will be found ... and hence, the tests still fail for me.
When I find out how to properly handle these typelib files, I expect both G::O::I and Gtk3 to build, test, and install just fine.
BTW, when I build Glib-1.301, some of the tests fail. I just ignore those failures and install the module anyway.
Cheers,
Rob
Update: Found it:
set GI_TYPELIB_PATH=C:\usr\local\lib\girepository-1.0
Dunno why they have to keep that such a closely guarded secret.
Anyway, with that in place, G::O::I-0.020 builds, tests and installs fine.
*I* still have some issues because I pretty much need to rebuild Cairo against the same binaries that I used for G::O::I .... for the same reason that I needed to re-build Glib.
But you should be right. | [reply]
[d/l] |
perl Makefile.PL
Warning (mostly harmless): No library found for -Wl,--export-dynamic
Trying to build test libraries... not OK
Writing Makefile for Glib::Object::Introspection
Writing MYMETA.yml and MYMETA.json
dmake
GObjectIntrospection.o:GObjectIntrospection.c:(.text+0x78f6): undefine
+d reference to `ffi_type_pointer'
GObjectIntrospection.o:GObjectIntrospection.c:(.text+0x7970): undefine
+d reference to `ffi_type_pointer'
GObjectIntrospection.o:GObjectIntrospection.c:(.text+0x79c0): undefine
+d reference to `ffi_type_pointer'
GObjectIntrospection.o:GObjectIntrospection.c:(.text+0x79f5): undefine
+d reference to `ffi_prep_cif'
GObjectIntrospection.o:GObjectIntrospection.c:(.text+0x7a23): undefine
+d reference to `ffi_call'
GObjectIntrospection.o:GObjectIntrospection.c:(.text+0x7fc2): undefine
+d reference to `ffi_type_pointer'
c:/strawberry/c/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686
+-w64-mingw32/bin/ld.exe: GObjectIntrospection.o: bad
reloc address 0x5c in section `.rdata'
c:/strawberry/c/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686
+-w64-mingw32/bin/ld.exe: final link failed: Invalid
operation
collect2: ld returned 1 exit status
dmake: Error code 129, while making 'blib\arch\auto\Glib\Object\Intro
+spection\Introspection.dll'
Skip blib\arch/Glib\Object\Introspection/Install/Files.pm (unchanged)
Skip blib\lib\Glib\Object/Introspection.pm (unchanged)
[ CC GObjectIntrospection.c ]
Running Mkbootstrap for Glib::Object::Introspection ()
C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e chmod -- 644 In
+trospection.bs
dlltool --def Introspection.def --output-exp dll.exp
[ LD blib\arch\auto\Glib\Object\Introspection\Introspection.dll ]
I must be missing an environment variable or something like that.
Thanks,
Don
| [reply]
[d/l] |
For the building of the test libraries to succeed (in the 'perl Makefile.PL' step) you need to set the GI_TYPELIB_PATH environment variable to point to the location of the typelib files:
set GI_TYPELIB_PATH=C:\usr\local\lib\girepository-1.0
I think that libffi-6.lib should define those undefined references. Though, for some reason, I also had to include libffi-6 from my Gtk-3 binaries - and my build links to C:/Gtk+3.6.1/lib/libffi.a ... not to C:/usr/local/libffi-6.lib
If you run 'dmake -v' we'll be able to see exactly which libraries it's trying to link to.
I've found a problem for us wrt Gtk3. That module has Cairo::GObject as a pre-requisite ... and I haven't been able to build that pre-requisite module in such a way that it's compatible with G::O::I.
The blocker is that the Cairo module (which is a prereq for Cairo::GObject) won't build against these binaries that we have in C:/usr/local. And if I use a Cairo::GObject that was built against different Gtk binaries, then the whole thing blows up.
Anyway, I guess we try and cross that bridge later ... or just jump off it.
These Glib based perl modules do all sorts of very cute stuff that make it difficult to hack. They're really designed to be built against a single complete set of Glib based binaries ... and we don't seem to have such a set for Windows. (We get some binaries from here, some others from there...)
Cheers,
Rob | [reply]
[d/l] |