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

[Joost <joost h-labahn de>]

Yes, perl was found, here the lines
from my configure.log in the atk dir (configure
first checks for perl5, only if not there for perl).

configure:14009: checking for perl5
configure:14025: found /bin/perl5
configure:14036: result: perl5
configure:14211: creating ./config.status

I repeat from my last mail (to keep this threat readible
for others, compiling on MinGW/Msys always ): The first make
is doing is invoking glib-mkenums. Without an existing /usr/bin/env
it fails with this message:

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

Creating /usr/bin/env manually then running make again gives:

make[2]: Entering directory `/e/Installer/GTK-src/atk-1.27.90/atk'
( cd . && glib-mkenums --fhead "#if defined(ATK_DISABLE_SINGLE_INCLUDES) &&
				!defined (__ATK_H_INSIDE__) &&
				!defined (ATK_COMPILATION)\n#error
					\"Only <atk/atk.h> can be included directly.\
					"\n#endif\n\n#ifndef__ATK_ENUM_TYPES_H__\n
					#define __ATK_ENUM_TYPES_H__\n\n
					#include <glib-object.h>\n\nG_BEGIN_DECLS\n" \
                        --fprod "/* enumerations from \"@filename \" */
...

        && (cmp -s tmp-atk-enum-types.h atk-enum-types.h || cp tmp-atk-enum-types.h atk-enum-types.h ) \
        && rm -f tmp-atk-enum-types.h \
        && echo timestamp > s-enum-types-h
/bin/sh: /mingw/bin/glib-mkenums: /usr/bin/env: bad interpreter: Permission denied

(a bit indented from me)

Both error messages are not very expressive, i
concluded from the second and configure.log that
perl is running and getting no permissions. That
is just an assumption of course.

And there is no #! for glib-mkenums in the
Makefile. The only match for searching it
in the Makefile is the line

GLIB_MKENUMS = glib-mkenums

Grepping 'glib-mkenums' recursively from the top-level dir of
atk only gives the same line in config.log and the
commentaries in atk-enum-types.c and atk-enum-types.h
quoted above (I've already checked these things while compiling).
That is the problem. Apparently the invocation
lies hidden anywhere in the interaction between make
and autoconf. Thus providing the result would not be
enough to overcome the problem.

Thanks again for attention, Joost