in reply to Re^2: Gtk3 Install Problems
in thread Gtk3 Install Problems

I think your best bet is to get someone else to build gobject-introspection for you. Maybe pester the person who built the Gtk3 Windows binaries.

I was trying to build version 1.34.2. I haven't checked to see whether there is something more recent (which might build more readily).
I use gcc-4.7.0 in the msys shell. Please /msg me if you can get Glib::Object::Introspection installed.
My notes regarding the awful hacks I used in my attempt to build the gobject-introspection C library are given below my sig (in readmore tags).

Cheers,
Rob
Run: export PATH=/c/_32/Python27:/c/GTK+3.6.1/bin:.:/usr/local/bin:/mingw/b +in:/bin export PKG_CONFIG_PATH=/c/GTK+3.6.1/lib/pkgconfig export GOBJECT_CFLAGS=-IC:/Gtk+3.6.1/include export GOBJECT_LIBS=-LC:/Gtk+3.6.1/lib export GMODULE_CFLAGS=-IC:/Gtk+3.6.1/include export GMODULE_LIBS=-LC:/Gtk+3.6.1/lib export GLIB_CFLAGS=-IC:/Gtk+3.6.1/include export GLIB_LIBS=-LC:/Gtk+3.6.1/lib export GIO_LIBS=-LC:/Gtk+3.6.1/lib export GIO_CFLAGS=-IC:/Gtk+3.6.1/include In configure script, change: PYTHON_LIBS="-L${py_prefix}/lib -lpython${PYTHON_VERSION}" to: PYTHON_LIBS="-L${py_prefix}/lib -lpython" Run the following configure command: ./configure --prefix=/c/Gtk+3.6.1 --disable-static --enable-shared LDF +LAGS="-L/c/Gtk+3.6.1/lib -L/c/Python27/Lib -L/c/_32/Python27/Lib/site +-packages -L/c/_32/Python27/libs" CPPFLAGS="-I/c/Gtk+3.6.1/include -I +/c/GTK+3.6.1/lib/glib-2.0/include -I/c/Gtk+3.6.1/include/glib-2.0 -I/ +c/_32/Python27/include" LIBS="-lgobject-2.0.dll -lgio-2.0.dll -lglib- +2.0.dll" Then, in all of the generated Makefiles: Makefile m4/Makefile tests/Makefile tests/offsets/Makefile tests/scanner/Makefile tests/repository/Makefile tests/warn/Makefile tests/doctool/Makefile docs/Makefile docs/reference/Makefile run the script at the bottom of this page in order to change: PYTHON_INCLUDES = -IC:\_32\Python27/include/python2.7 PYTHON_LIBS = -LC:\_32\Python27/lib -lpython PYTHON_LIB_LOC = C:\_32\Python27/lib to: PYTHON_INCLUDES = -I/c/_32/Python27/include/python2.7 PYTHON_LIBS = -L/c/_32/Python27/lib -lpython PYTHON_LIB_LOC = /c/_32/Python27/lib Turn on verbosity for 'make' by running 'make V=1'. Before running make, modify giscanner/giscannermodule.c to load msvcr9 +0.dll instead of msvcr71.dll. (Earlier python binaries use msvcr71.dll, but my 2.7 uses + msvcr90.dll.) That gets us to: IOError: [Errno 2] No such file or directory: '.\\.libs\\.libs\\_gisca +nner.pyd' 'cd' to .libs folder, run 'mkdir .libs', 'cd ..'. Copy .libs/_giscanner.pyd to .libs/.libs/_giscanner.pyd and re-run 'ma +ke V=1'. Results in: WindowsError: [Error 193] %1 is not a valid Win32 application __END__ use strict; use warnings; my @make = qw( Makefile m4/Makefile tests/Makefile tests/offsets/Makefile tests/scanner/Makefile tests/repository/Makefile tests/warn/Makefile tests/doctool/Makefile docs/Makefile docs/reference/Makefile ); for my $mf(@make) { print "Amending $mf\n"; open RD, '<', $mf or die "Can't open $mf for reading: $!"; open WR, '>', "${mf}_new" or die "Can't open ${mf}_new for writing: +$!"; while(<RD>) { $_ =~ s/PYTHON_INCLUDES = \-Ic:\\_32\\Python27\/include\/python2\. +7/PYTHON_INCLUDES = \-I\/c\/_32\/Python27\/include\/python2\.7/; $_ =~ s/PYTHON_LIBS = \-Lc:\\_32\\Python27\/lib \-lpython/PYTHON_L +IBS = \-L\/c\/_32\/Python27\/lib \-lpython/; $_ =~ s/PYTHON_LIB_LOC = c:\\_32\\Python27\/lib/PYTHON_LIB_LOC = \ +/c\/_32\/Python27\/lib/; $_ =~ s/C:\//\/c\//gi; print WR $_; } close RD or die "Couldn't close $mf after reading: $!"; close WR or die "Couldn't close ${mf}_new after writing: $!"; die "Couldn't rename $mf to ${mf}_orig" unless rename $mf, "${mf}_orig"; die "Couldn't rename ${mf}_new to $mf" unless rename "${mf}_new", $mf; }

Replies are listed 'Best First'.
Re^4: Gtk3 Install Problems
by drdon (Novice) on Feb 24, 2014 at 00:59 UTC

    Check out https://github.com/tomnotcat/glib-win32. If that helps let me know. I would still like to get Gtk3 installed.

    Thanks, Don

      Looks promising. (I'm using the mingw.org port of gcc-4.7.0 btw.) I downloaded the package and unpacked it to:

      C:\usr\local
      Then I cut'n'pasted everything from C:/usr/local/glib-win32-master folder to C:/usr/local - ie moved those directories up one level.
      The pc files (that the Glib-Object-Introspection-0.020 build process will reference have {prefix} set to /usr/local/ ... and I'm thinking it's best to honor that spec. Added /usr/local/bin and my GTK-3 bin to the beginning of the PATH. For me:
      set PATH=C:\usr\local\bin;C:\GTK+3.6.1\bin;%PATH%

      Set the PKG_CONFIG_PATH envvar to include both C:\usr\local\lib\pkgconfig and the GTK-3 pkgconfig folder.
      For me:
      set PKG_CONFIG_PATH=C:\usr\local\lib\pkgconfig;C:\GTK+3.6.1\lib\pkgconfig

      Set the CPATH envvar to include the introspection headers:
      set CPATH=C:\usr\local\include\gobject-introspection-1.34.2

      Then created a copy of libffi.dll.a named libffi.a.
      ie copied C:\GTK=3.6.1\lib\libffi.dll.a to C:\GTK=3.6.1\lib\libffi.a

      Then created a copy of girepository.lib named libgirepository-1.0.a:
      ie copied C:\usr\local\lib\girepository.lib to C:\usr\local\lib\libgirepository-1.0.a

      Then I ran the 'perl Makefile.PL', 'dmake' mantra.

      That built a loadable version of Glib-Object-Introspection-0.020 ... but the test libraries aren't being built (during the Makefile.PL step), so all tests are skipped.
      I still need to work out what's going wrong there. I'll update this post when (if) I get that sorted.

      Then we get to see what horrors await us when we try to build the Gtk3 module. (Hopefully none !!)

      Don, if you're impatient, just build and install Glib-Object-Introspection-0.020 as per the outline given above, and then see what happens when you try to build Gtk3.
      Don't worry (for the moment) about the tests being skipped.

      Cheers,
      Rob

      Update: Turns out that we don't have a /usr/local/bin/g-ir-scanner.exe ... instead we have /usr/local/bin/g-ir-scanner.py.
      And, to build the test libraries on Win32, we're hit with this in the Makefile.PL:
      if ($^O eq 'MSWin32') { my @path = File::Spec->path; my $found = 0; foreach my $base (map { File::Spec->catfile ($_, 'g-ir-scanner') + } @path) { if (-f $base) { $gir_cmd = qq(python $base); $found = 1; last; } } return 0 unless $found;
      Well, of course, the file is called 'g-ir-scanner.py' not 'g-ir-scanner' ... therefore $found doesn't get set and 0 is returned.
      Changing the 'g-ir-scanner' to 'g-ir-scanner.py' means that the file *does* get found and the python command then ultimately gets executed. But, unfortunately, that just errors out with:
      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
      Now, I don't know what's needed there. (All I know about python is that there's a lot of half-witted wankers who reckon it's the ant's pants.)

      So, I'm currently left to wonder whether the G::O::I I've just built is right to go, or whether there are problems with it that won't be properly revealed until the tests are run.
      (BTW, if you want to see the diagnostics as the test libraries are being built, there's a variable in the Makefile.PL named $pipe that needs to be changed from 1>NUL 2>NUL to the empty string.)

      I installed G::I::O-0.020 and then tried building GTk3-0.016 (which is apparently a pure-perl module) but all of the test scripts I tried errored out (and hanged) with:
      t/00-init.t .................... (perl.exe:4968): Glib-GObject-CRITICAL **: ..\..\..\gobject\gtype.c:27 +22: You forgot to call g_type_init() (perl.exe:4968): Glib-CRITICAL **: file ..\..\..\glib\gthread.c: line +713: assertion `result != 0' failed (perl.exe:4968): Glib-GObject-CRITICAL **: file ..\..\..\gobject\gobje +ct.c: line 1538: assertion `G_TYPE_IS_OBJECT (object_type)' failed
      Perhaps this is because G::O::I-0.020 is no good, or perhaps it's something that might be fixed quite simply. I'd recommend that a bug report, containing the above output, be filed against Gtk3-0.016 ... and take it from there. The bug report should also mention that all of the G::O::I tests were skipped because the test libraries were not built, but that G::O::I loads ok.
        Perhaps this is because G::O::I-0.020 is no good, or perhaps it's something that might be fixed quite simply

        I've just had a quick look at the G::O::I documentation and it says:
        To allow Glib::Object::Introspection to create bindings for a libr +ary, it must have installed a typelib file, for example "$prefix/lib/girepository-1.0/Gtk-3.0.typelib".
        I can see the various typelib files in C:/usr/local/lib/girepository-1.0/ ... but G::O::I did not make any attempt to install them anywhere.
        To where should they go and how does one get them to go there ?
        How does one arrange things so that those typelib files are found automatically ? The docs state that they'll be found automatically if "you use typelibs from system directories, or if your environment is set up correctly", but provide no further details AFAICS.

        Cheers,
        Rob

        Update: ppm packages (32-bit perl only) for G::O::I-0.020 have been uploaded.
        Once installed, the various typelib files will be found in the perl/site/lib/Glib/typelibs folder - in case they're needed.
        It would be interesting to know whether something useful can be done with these ppm packages.