compiling python2.5 on linux under wine

[lkcl]

>  ... aaaand, that means disabling setup.py or hacking it significantly
> to support a win32 build, e.g. to build pyexpat, detect which modules
> are left, etc. by examining the remaining vcproj files in PCbuild.

ok - i started the hacking.

the first bit of hacking is this, in distutils/sysconfig.py,
added to _init_nt()

    try:
        filename = get_makefile_filename()
        parse_makefile(filename, g)
    except IOError, msg:
        my_msg = "invalid Python installation: unable to open %s" %
filename
        if hasattr(msg, "strerror"):
            my_msg = my_msg + " (%s)" % msg.strerror

        raise DistutilsPlatformError(my_msg)

    # load the installed pyconfig.h:
    try:
        prefix = EXEC_PREFIX
        prefix = os.path.join(prefix, "PC")
        filename = os.path.join(prefix, "pyconfig.h")
        parse_config_h(file(filename), g)
    except IOError, msg:
        my_msg = "invalid Python installation: unable to open %s" %
filename
        if hasattr(msg, "strerror"):
            my_msg = my_msg + " (%s)" % msg.strerror

        raise DistutilsPlatformError(my_msg)

    global _config_vars
    _config_vars = g


that gets me part-way - at least i get... oh dear :

    self.build_extensions()
  File "../setup.py", line 183, in build_extensions
    self.compiler.set_executables(**args)
  File "Z:\mnt\src\python2.5-2.5.2\lib\distutils\ccompiler.py", line
165, in set_executables
    (key, self.__class__.__name__)
ValueError: unknown executable 'compiler_so' for class MSVCCompiler

whoops :)

so, next, we hack in a compiler, in to ... ooo, let's saaay...
distutils/cygwinccompiler.py, just for fun.

now we get this!

winegcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -I. -IZ:\mnt\src\python2.5-2.5.2\./Include -I. -
IInclude -I../Include -I/usr/local/include -IZ:\mnt\src
\python2.5-2.5.2\include -IZ:\mnt\src\python2.5-2.5.2\PC -c Z:\mnt\src
\python2.5-2.5.2\Modules\_ctypes/_ctypes_test.c -o z:\mnt\src
\python2.5-2.5.2\modules\_ctypes\_ctypes_test.o

wha-hey!

but... oh dear.

oh dear number 1)

firstly, err.... this is cross-compiling - those path names are
bullshit because actually we're compiling on.... LINUX damnit, not
windows.  hmm.... there's something to work around that one, perhaps,
by installing the mingw32 compiler under wine (o god i've done that
before, it's dreadfully slow)

oh dear number 2)

  File "Z:\mnt\src\python2.5-2.5.2\lib\os.py", line 562, in spawnv
    return _spawnvef(mode, file, args, None, execv)
  File "Z:\mnt\src\python2.5-2.5.2\lib\os.py", line 545, in _spawnvef
    wpid, sts = waitpid(pid, 0)
NameError: global name 'waitpid' is not defined

 err.... oh - ok, found another missing function: spawnv.  so, added
 that, in PC/pcbuild.h:

#ifdef __WINE__
#define HAVE_SPAWNV
#endif

 and after some futzing around with yet more #ifdefs in posixmodule.c
 we have another build - this time using wine's spawnv so it doesn't
 try to find a non-existent waitpid aaannnd SPLAT yesss, we get the
 crash-output from winegcc:

Failed to configure _ctypes module
building '_ctypes_test' extension
winegcc -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -
Wstrict-prototypes -I. -IZ:\mnt\src\python2.5-2.5.2\./Include -I. -
IInclude -I../Include -I/usr/local/include -IZ:\mnt\src
\python2.5-2.5.2\include -IZ:\mnt\src\python2.5-2.5.2\PC -c Z:\mnt\src
\python2.5-2.5.2\Modules\_ctypes/_ctypes_test.c -o z:\mnt\src
\python2.5-2.5.2\modules\_ctypes\_ctypes_test.o
wine: Unhandled page fault on read access to 0x7265704f at address
0x601ec25b (thread 001c), starting debugger...
Unhandled exception: page fault on read access to 0x7265704f in 32-bit
code (0x601ec25b).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:601ec25b ESP:0032c70c EBP:0032c718 EFLAGS:00010206(   - 00      -
RIP1)
 EAX:7265704f EBX:7bc8a7a4 ECX:00000003 EDX:604ab3d7
 ESI:0032c848 EDI:7265704f
Stack dump:
0x0032c70c:  7bc6859d 7265704f 6056a0b8 0032c788
0x0032c71c:  603fd0eb 7265704f 006e9544 001bc84c
0x0032c72c:  006c574c 6056b82c 605721a0 00000002
0x0032c73c:  0032c7d8 718e21fe 0016329c 7265704f
0x0032c74c:  00730065 002e0074 0000006f 00159320
0x0032c75c:  603aa590 001b3f0c 005086e0 00000004
Backtrace:
=>1 0x601ec25b strlen+0xb() in libc.so.6 (0x0032c718)
fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const
value degToRad (a)
  2 0x603fd0eb do_mkvalue+0x3db(p_format=<register ESI not in topmost
frame>, p_va=<is not available>, flags=0x0) [/mnt/src/python2.5-2.5.2/
build/../Python/modsupport.c:419] in python (0x0032c788)
  3 0x603fcc6d do_mktuple+0x7d(p_format=0x32c848, p_va=0x32c844,
endchar=0x29, n=0x2, flags=0x0) [/mnt/src/python2.5-2.5.2/build/../
Python/modsupport.c:268] in python (0x0032c7b8)
 .....
 .....


 hey, this is fun!  let's try a crazed compile of python and see what
falls over, wheeeee :)


 ... much as this seems to be consuming much of my time, for some
bizarre reason i just can't seem to stop.


 anyway - yes, this is effectively cross-compiling, and so the
python25.exe and environment created is unfortunately expecting to see
a windows-like environment.

 bugger.

 i'll ask on the wine lists if there's a "back-translator".  winegcc
and wineg++ are wrapper-scripts that wrap gcc and g++ to "make it look
like" you're compiling for win32 when in fact you're compiling under
linux.

 if there was a back-translation of that concept, that recognised z:
\blahblah and back-translated it into /unix/blah then it would be
possible to get away with specifying _that_ script as the compiler,
which would then pass winegcc as _its_ script....

 yuukkk!