GNOME Bugzilla – Bug 314673
win32 build fixes (autotools)
Last modified: 2009-01-19 20:10:45 UTC
Distribution/Version: XP (MinGW+MSYS) I have a patch forthcoming that allows pygtk to be built out-of-the-box with MinGW and MSYS. It involves adding a "new" m4 macro (AM_CHECK_PYTHON_LIB), modified to work with a win32 build, and related changes to the "Makefile.am"s and "configure.in".
Created attachment 51438 [details] [review] win32 (MinGW + MSYS) build patch
Created attachment 51472 [details] [review] My attempt to get autotools to play nicely on Win32 This is the same technique we use for building pygimp. It's a lot simpler than the first patch, and avoids rummaging through the python Makefiles. It's untested on Win32 itself, so I'd appreciate someone trying.
Manish: a lot better, now we just need someone to test it on win32? Mark can you help out here please? Btw, why is it called PYLINK_LIBS and not just PYTHON_LIBS?
I used PYLINK_LIBS in the offchance that automake may define PYTHON_LIBS at some future point. It's not a strong preference however.
Created attachment 51531 [details] [review] updated/merged patch using Manish's patch and this configuration (because I have both a mingw-compiled and the official python): PATH="/c/temp/python:.:/usr/local/bin:/mingw/bin:/bin" PYTHONHOME= PYTHONPATH= ./configure && make [...] if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -Ic:/temp/python/include -IC:/temp/msys/1.0/local/include/glib-2.0 -IC:/temp/msys/1.0/local/lib/glib-2.0/include -IC:/temp/msys/1.0/local/include/glib-2.0 -IC:/temp/msys/1.0/local/lib/glib-2.0/include -DPLATFORM_WIN32 -O3 -march=i686 -mms-bitfields -I/usr/local/include -Wall -std=c9x -fno-strict-aliasing -MT gobject_la-pygtype.lo -MD -MP -MF ".deps/gobject_la-pygtype.Tpo" -c -o gobject_la-pygtype.lo `test -f 'pygtype.c' || echo './'`pygtype.c; \ then mv -f ".deps/gobject_la-pygtype.Tpo" ".deps/gobject_la-pygtype.Plo"; else rm -f ".deps/gobject_la-pygtype.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -Ic:/temp/python/include -IC:/temp/msys/1.0/local/include/glib-2.0 -IC:/temp/msys/1.0/local/lib/glib-2.0/include -IC:/temp/msys/1.0/local/include/glib-2.0 -IC:/temp/msys/1.0/local/lib/glib-2.0/include -DPLATFORM_WIN32 -O3 -march=i686 -mms-bitfields -I/usr/local/include -Wall -std=c9x -fno-strict-aliasing -MT gobject_la-pygtype.lo -MD -MP -MF .deps/gobject_la-pygtype.Tpo -c pygtype.c -DDLL_EXPORT -DPIC -o .libs/gobject_la-pygtype.o /bin/sh ../libtool --tag=CC --mode=link gcc -O3 -march=i686 -mms-bitfields -I/usr/local/include -Wall -std=c9x -fno-strict-aliasing -L/usr/local/lib -o gobject.la -rpath c:\temp\python\Lib\site-packages/gtk-2.0 -module -avoid-version -no-undefined -export-symbols-regex initgobject gobject_la-gobjectmodule.lo gobject_la-pygboxed.lo gobject_la-pygenum.lo gobject_la-pygflags.lo gobject_la-pygobject.lo gobject_la-pygmaincontext.lo gobject_la-pygmainloop.lo gobject_la-pygparamspec.lo gobject_la-pygpointer.lo gobject_la-pygiochannel.lo gobject_la-pygsource.lo gobject_la-pygtype.lo -LC:/temp/msys/1.0/local/lib -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lintl -liconv -Lc:/temp/python/libs -lpython24 libtool: link: only absolute run-paths are allowed I believe this has to do with pyexecdir and pythondir not having the correct separator. In this patch, I've merged some of Manish's changes and added a check for a mingw version such as my own so that it will use the unix-style check for the include dir. In addition, I added a patch to runtests.py so test_mainloop.py won't run if the tests are run on win32 (os.fork() doesn't work) I still need to look at getting the non-python modules (like pygtk-demo, the defs, pygtk-codegen-2.0, etc.) installed into the python tree as opposed to the MinGW tree. Or is that even necessary?
Created attachment 51676 [details] [review] patch v3 What's changed: * moved the PYLINK_LIBS stuff into a macro so I can submit all of the m4 changes to automake when I'm done (initial suggestion by jdahlin) * made the py_mingw related code more portable, thanks to yosh's comments on IRC
A couple more comments: > -AM_PATH_PYTHON(2.3.5) > +AM_PATH_PYTHON(2.3.5,, [AC_MSG_ERROR(could not find Python)]) AM_PATH_PYTHON provides a default error message. Is there a reason why you overrid it? > +if test "x$platform_win32" = "xyes"; then If you plan to push this macro to upstream automake, you can't use $platform_win32, as automake/autoconf doesn't supply that on its own. You can use 'if test "$PYTHON_PLATFORM" = "win32"' like in the other test however.
mark lee, can you please answer manish's questions? is this still an issue?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!