After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 314673 - win32 build fixes (autotools)
win32 build fixes (autotools)
Product: pygtk
Classification: Bindings
Component: general
Other Windows
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Reported: 2005-08-27 21:53 UTC by Mark Lee
Modified: 2009-01-19 20:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

win32 (MinGW + MSYS) build patch (5.00 KB, patch)
2005-08-27 21:56 UTC, Mark Lee
none Details | Review
My attempt to get autotools to play nicely on Win32 (6.11 KB, patch)
2005-08-28 18:28 UTC, Manish Singh
none Details | Review
updated/merged patch (6.48 KB, patch)
2005-08-30 00:18 UTC, Mark Lee
none Details | Review
patch v3 (7.21 KB, patch)
2005-09-01 20:22 UTC, Mark Lee
reviewed Details | Review

Description Mark Lee 2005-08-27 21:53:54 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 ""s
and "".
Comment 1 Mark Lee 2005-08-27 21:56:25 UTC
Created attachment 51438 [details] [review]
win32 (MinGW + MSYS) build patch
Comment 2 Manish Singh 2005-08-28 18:28:03 UTC
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.
Comment 3 Johan (not receiving bugmail) Dahlin 2005-08-29 21:39:50 UTC
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?

Comment 4 Manish Singh 2005-08-29 21:42:02 UTC
I used PYLINK_LIBS in the offchance that automake may define PYTHON_LIBS at some
future point. It's not a strong preference however.
Comment 5 Mark Lee 2005-08-30 00:18:09 UTC
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	-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 -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 so 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?
Comment 6 Mark Lee 2005-09-01 20:22:45 UTC
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
Comment 7 Manish Singh 2005-09-01 21:54:46 UTC
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.
Comment 8 André Klapper 2006-10-09 15:14:56 UTC
mark lee, can you please answer manish's questions?
is this still an issue?
Comment 9 Christoph Wurm 2009-01-19 20:10:45 UTC
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.