Re: Compiling gtk+ with MinGW on WindowsXP - perl problem

[Tor Lillqvist <tml iki fi>]

(Note that this list, gtk-list, is definitely oriented towards GTK+
application writers, so your mail would have been better suited for
gtk-devel-list, which is about developing GTK+ itself.)

> following the instructions from
> http://kemovitra.blogspot.com/2009/06/compiling-gtk-2-for-windows.html
> i succeeded in compiling the full gtk-stack these days with MinGW/Msys
> on WindowsXP SP3. Hopefully this page will prevail.

Ah, nice, one more webpage showing how to build the GTK+ stack on
Windows. The more there are of these, the more people there hopefully
are who understand what is going on. Or alternatively, the more people
just blindly following instructions written by others instead of
understanding what they are doing.. (I am not implying you would
belong to the latter group.)

> Here is a small bug in the build sources: make install doesn't copy
> zlib.h and zconf.h to /usr/include.

This if course has nothing to do with building GTK+. zlib is a
completely separate package. There is little reason do desperately try
to build all 3rd-party dependencies of GTK+, too, if one just wants to
hack on GTK+ itself. Unless one wants the learning experience, of
course. After all, some people want to build their complete Linux
systems by themselves, too. (And even less reason if one wants to just
write GTK+ applications, of course. .).

Anyway, I would definitely advice *not* to install self-built stuff
into MSYS's /usr tree (/usr/include, /usr/lib, /usr/bin etc). It's
much cleaner to keep only stuff from MSYS's download page in the MSYS
tree. You shouldn't install stuff you build yourself and which aren't
package managed into /usr on Linux (or UNIX in general) systems
either.

> Apparently perl tries
> to write something into /usr/bin/env, which doesn't exist.

Hmm, that sounds totally weird, are you sure about this? What hashbang
line (the #! thing) does the glib-mkenums script you built (it is
generated from glib-mkenums.in by the configuration process) start
with?

> Creating it
> manually - from the msys shell or not - changes the error message to
> include "Permission denied" then (of course i did all this with admin
> privileges).

Nah, using admin privileges to build software is not a good idea. And
if you just make sure the installation prefix you will use is
writable, it should work just fine to run "make install" also as a
normal user. "Permission denied" is just misleading most likely.

> Searching the net i found out that getting msys's chmod to work on
> XP is a well-known problem.

Hmm, I don't know what you mean here, what does chmod have to do with
glib-mkenums?

 > Apparently nobody has a definite answer to it.

I don't know what chmod problem you specifically mean, but in general,
trying to emulate UNIX's  rwxrwxrwx protection bits in MSYS (or
Cygwin; MSYS is a fork of Cygwin) will never work 100% as the
underlying Windows protection mechanism (access control lists,
assuming NTFS) is totally different. And especially in MSYS, the whole
point of MSYS is to be used just when building software that will then
run "natively" on Windows without any UNIX emulation, so any chmod
used during the build process is pretty pointless.

> There are files atk-enum-types.c and .h in the sources, headed by
> /* Generated data (by glib-mkenums) */. Having gained trust in the
> quality of the code i proceeded with make --ignore-errors. All the
> same - the existence of enum-types.c and .h too - with pango and finally
> gtk. And the libgtk-win32-2.0-0.dll thus won works well with my large
> python applications.

Sorry, I don't really understand what you mean here.

> But it doesn't work completely, i got the g_loadable_icon_load error,
> which is discussed in a mozilla context elsewhere, when trying to
> use anything that requires gtk's stock icons. Thus i cannot see
> widgets with gtk-demo, and my apps are crashing on right-clicks
> in Entries. Of course i am not sure, that this is related to the
> compilation problem (perhaps not).

Hmm, thart sounds indeed like something is completely wrong in your
build. Did you manage to produce DLLs at all, or did libtool play
over-protective once again and decice to make just static archives?

> At this point nothing forces me to use the self-compiled binaries.
> But having worked a day on it,

Trust me, spending just one day on getting one's build working is
nothing, if you are doing it for the first time. Expect to hack on it
for several days before you get an understanding of what is going on
and what you are doing...

> i'd be very fond of seeing a clean compilation process.

The definitely easiest and cleanest way to build the GTK+ stack for
Windows is to cross-compile it from Linux.

> Is there any way to work around these perl scripts ?

What Perl scripts? You mean glib-mkenums? Basically they either just
work, or not at all, as far as I know. Are you sure "these perl
scripts" is really the root problem for you?

Or is it just that as you apparently is a Python user, you find it
natural to assume anything Perl-related must be the root problem...;)

> Unfortunately i couldn't find any line starting them in
> the Makefile, in config.status or elsewhere. I'd also like to use
> the MinGW/Msys core only.

glib-mkenums is a UNIX-style executable script that starts with a #!
line telling what "interpreter" to use to run it, thus it works only
inside a UNIX emulation environment, i.e. MSYS. In a Makefile that is
processed by MSYS Make glib-mkenums is run as if it was an executable.
MSYS takes care of noticing that it is an executable script and
actually running the specified interpreter on it.

--tml