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


thanks for answer. True, that zlib point. And the webpage i quoted is
wrong with --prefix /mingw, that's right.

As i wrote proceeding further with --ignore-errors gave me perfectly
usable libgtk-win32-2.0-0.dll (and there were no other error messages
while compiling atk, pango and gtk). Because of the icon-stock problem
i could not run the normal tests, but my application - using 2 theming
engines mixed, having several TreeViews, scaling gtk.Images on resize and
more - are a test in itself. They run with the built libgtk-win32-2.0-0.dll.

All has gone right in building and while working a whole day on it, i of
course checked, whether the intermiediate results existed or not. I knew
what i did - my first autoconf/make build was tcl/tk around 1995, on linux
at that time (with success, i remember to have to change a #define in the
sources). But i do these things only from time to time.

The problem with chmod is, that XP simply has no mechanisms to store the result
of chmod -m a+w, for example. I also have no ideas, why perl didn't inherit
my admin rights, but it apparently it did. Here is the error line without
an existing /usr/bin/env

/bin/env: perl -w: No such file or directory

Creating it manually then running make again gives

/bin/sh: /mingw/bin/glib-mkenums: /usr/bin/env: bad interpreter: Permission denied

Both at the first step in make as the result of the commands

cd . && glib-mkenums ... -fprod "*/ enumerations from \"@filename \" ...

Thus my question again: Is there a way to work around glib-mkenums ?


Tor Lillqvist schrieb:
(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
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

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 by the configuration process) start

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

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

 > 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]