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
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]
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/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/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
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]
* 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
A couple more comments:
> +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
> +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.