[issue1597850] Cross compiling patches for MINGW
Roumen Petrov added the comment: Proposed patch is mostly for cross compilation in general. Now this is implemented differently and I think that all proposed updates are already addressed. Also I can not see relation with gcc( mingw ) builds. What about to close issue as fixed ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Han-Wen Nienhuys added the comment: yeah, whatever. (only 7 years to close an issue. Yay for open-source.) -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by wrobell wrob...@pld-linux.org: -- nosy: +wrobell ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Gregory P. Smith g...@krypto.org: -- nosy: -gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Éric Araujo mer...@netwok.org: -- versions: +Python 3.3 -3rd party, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Alexis Metaireau ale...@notmyidea.org: -- nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Éric Araujo mer...@netwok.org: -- versions: +3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Roumen Petrov bugtr...@roumenpetrov.info added the comment: -1 for the patch (after review of cross-3.0-0.7.diff) : 1) AC_CHECK_TOOLS(CC,gcc cc) and AC_CHECK_TOOLS(CXX,g++ c++) is bogus 2) $CC -dumpmachine when is added AC_CANONICAL_HOST is bogus 3) if (strcmp(buffe,me) 123)) is buggy Good point is setup.py is to exclude default searches for header/libraries in /usr/XXX directories . Note that this is requested in other issues not related to cross compilation. About pgen build i'm not sure that is wort to cross-build as there is no reason to recreate files , right ? To me this is only dependency issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Éric Araujo mer...@netwok.org added the comment: Distutils is normally frozen for new features, but in this case the changes are small and useful enough to warrant an exception in my opinion (provided the patch is ported to 3.2 and gets a positive review). Tarek, do you agree? -- assignee: - tarek components: +Distutils, Distutils2 nosy: +eric.araujo, tarek stage: - patch review type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: the changes are small which patch are you referring to? They look quite large to me. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Éric Araujo mer...@netwok.org added the comment: cross-3.0-0.7.diff only changes a few lines in build_ext. I was specifically talking only about distutils changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Martin v. Löwis mar...@v.loewis.de added the comment: For cross-3.0-0.7.diff, we would need a real name and a contributor agreement. Of course, attribution is muddy here; this literally goes back to sraue's patch, which in turn goes back to scott.tsai's patch. I'm still uncertain what it is that this patch actually achieves. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Gregory P. Smith g...@krypto.org: -- nosy: +gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Joshua Kinard ku...@gentoo.org added the comment: Anyone gotten farther on getting Python-2.5.x to cross-compile? I'm trying to get x86_64-pc-linux-gnu -- mipsel-unknown-linux-gnu, and after some hacking at the last updated cross-2.5.1.patch, plus a fix for the %zd printf bugaboo, plus adding in config.sub/config.guess files, I'm able to get it moving a little. But I'm running into the same failure as described in Message #56846 and I'm not quite sure how to properly work around that. Can't hack around it -- the entire build is automated from a Gentoo ebuild, so I need to be able to tweak something in Makefile.pre.in or configure.in to fix this...somehow. Ran some quick checks, and even with passing -I/usr/include to CPPFLAGS_FOR_BUILD, and running the host compiler directly on the command line, It's picking up wrong values for LONG_BIT and SIZEOF_LONG (I think). LONG_BIT = 64 SIZEOF_LONG = 4 So the test LONG_BIT != (SIZEOF_LONG * 8) succeeds and hits the #error in pyport.h Can't use a newer Python, including 2.6, 2.7-trunk, or even 3.0. Gentoo's primary package manager, portage, is currently dependent on 2.5.x (we're using 2.5.4 specifically right now). So Roumen's patch doesn't work at all (I've already tried backporting). Ideas perhaps? -- nosy: +kumba ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
n03702 [EMAIL PROTECTED] added the comment: There is port of cross-2.6-0.7.diff patch for python 3.0 final -- nosy: +n03702 Added file: http://bugs.python.org/file12252/cross-3.0-0.7.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Stephan Raue [EMAIL PROTECTED] added the comment: when i crosscompile Python 2.6 with Patch cross-2.6-0.7.diff which is based on cross-2.5.1.patch i become follow error: ld -s -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict- prototypes -I. -IInclude -I./Include build/temp.linux-i686- 2.5/home/stephan/OpenELEC/build.i386.uClibc/Python- 2.6/Modules/_multiprocessing/multiprocessing.o build/temp.linux-i686- 2.5/home/stephan/OpenELEC/build.i386.uClibc/Python- 2.6/Modules/_multiprocessing/socket_connection.o build/temp.linux-i686- 2.5/home/stephan/OpenELEC/build.i386.uClibc/Python- 2.6/Modules/_multiprocessing/semaphore.o -L/usr/lib -lpython2.5 -o build/lib.linux-i686-2.5/_multiprocessing.so ld: unrecognized option '-DNDEBUG' ld: use the --help option for usage information creating build/temp.linux-i686-2.5/libffi checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... /home/stephan/OpenELEC/build.i386.uClibc/toolchain/bin/i686-geexbox- linux-uclibc-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. Failed to configure _ctypes module what can i do libffi compiles with --host and --build when i compile libffi standalone and run configure with --with-system- ffi the error is the same. -- nosy: +sraue versions: +Python 2.6 -Python 2.5 Added file: http://bugs.python.org/file12093/cross-2.6-0.7.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
rwmjones [EMAIL PROTECTED] added the comment: Just to clarify, in the MinGW case we are interested in: build = Fedora Linux, usually i386 or x86-64 (but not always) host = Windows i386 We can, to a limited extent, run the host binaries on the build system, using Wine (the Windows emulator). This doesn't always work, and in any case is usually regarded as the wrong thing to do because Wine is a very large and complicated build dependency which requires, amongst other things, a working X server. Also since Wine doesn't run on anything which is not x86-like, if we have to run Wine during the build then we cannot cross-compile from other Fedora build systems, specifically ppc and sparc. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Roumen Petrov [EMAIL PROTECTED] added the comment: Hi rwmjones, Please, could you test patch from issue3871 - python modules are build as setup.py is run from python found on the build system. So I don't expect issue with ppc and sparc. Minor issue is pgen.exe - work around touch grammar files. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Han-Wen Nienhuys [EMAIL PROTECTED] added the comment: I'm still interested in this, but the last time I did anything, I jumped through all the hoops (see conversation here), and not a single change was put into trunk. I'm not very enthousiastic about spending a lot time on this again. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Han-Wen Nienhuys [EMAIL PROTECTED] added the comment: @Luke the compiling strategy for Python (IIRC) is to compile everything, including modules that will never work, and use compiler errors as a signal to not include a module in the result. this is what I end up with for 2.4 ./usr/bin/libpython2.4.dll ./usr/bin/imageop.dll ./usr/bin/_codecs_hk.dll ./usr/bin/_codecs_jp.dll ./usr/bin/_heapq.dll ./usr/bin/_random.dll ./usr/bin/cPickle.dll ./usr/bin/cStringIO.dll ./usr/bin/regex.dll ./usr/bin/collections.dll ./usr/bin/_locale.dll ./usr/bin/_testcapi.dll ./usr/bin/_codecs_tw.dll ./usr/bin/pyexpat.dll ./usr/bin/_hotshot.dll ./usr/bin/mmap.dll ./usr/bin/math.dll ./usr/bin/binascii.dll ./usr/bin/array.dll ./usr/bin/smtpd.py ./usr/bin/cmath.dll ./usr/bin/audioop.dll ./usr/bin/_codecs_kr.dll ./usr/bin/parser.dll ./usr/bin/itertools.dll ./usr/bin/_csv.dll ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Martin v. Löwis [EMAIL PROTECTED] added the comment: the compiling strategy for Python (IIRC) is to compile everything, including modules that will never work, and use compiler errors as a signal to not include a module in the result. I don't think this can work in the cross-compilation case, though (or the entire setup.py part of it can't really work). It uses the target's python binary to run setup.py, compiles the modules, and then tries to load them. In a cross-compilation case, you can't run the target python binary, and even if you use a host python instead, you can't load the target extension modules (unless the cross compilation is for the same microprocessor and operating system - a case I'm not very much interested in). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Roumen Petrov [EMAIL PROTECTED] added the comment: I found the patch cross-2.5.1.patch as too limited. I'm interesting in this topic and I post patch in issue3871 that continue work from issue841454 and issue1412448. -- nosy: +rpetrov ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Roumen Petrov [EMAIL PROTECTED] added the comment: Martin meaning of target and host is different. There is no reason to use Canadian Cross: build-host-target. It is about more simple cross-compilation case: build-host. About loading of modules in build environment: some OS-es can run binaries from other OS-es. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Martin v. Löwis [EMAIL PROTECTED] added the comment: Martin meaning of target and host is different. There is no reason to use Canadian Cross: build-host-target. It is about more simple cross-compilation case: build-host. Terminology issues aside, I hope people still will understand my objection. I meant it this way: - host system: system hosting Python build process - target system: system intended to run resulting Python executable Whether that conforms to autoconf should be irrelevant, as long as we aren't talking about configure.in changes. About loading of modules in build environment: some OS-es can run binaries from other OS-es. Sure. However, I don't think this is the general case for cross-compilation, and I don't think cross-compilation support in Python should assume this is possible. Instead, cross-compilation should assume that build system and target system have anything in common (except that target headers and for-target cross tools are installed on the build system). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Roumen Petrov [EMAIL PROTECTED] added the comment: Now in mingw case the common is python posix build system. If the cross-compilation work what is problem to build in native environment? Personally I prefer to build in cross environment. It is convenient. There is no problem to run python tests in the native environment. In emulated environment most of the python test run smoothly. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: ok. what's not explained, and isn't clear, is exactly whether you're supposed to - or even _capable_ of - cross-compiling the _entire_ python sourcecode base with mingw32, or whether you're supposed to get _just_ the python.exe interpreter, and, maybe if you're lucky, libpython.a (or libpython.dll - whatever). i got quite a long way, as you can see, in cross-compiling posixmodule.c _by mistake_ - before realising that the whole python sourcecode base is completely inadequately set up for cross-compiling, but is specialised hard-coded to compile python under msvc _only_. so, when doing the cross-compile, it was actually being detected as a _unix_ compile, not a _win32_ compile. #define WIN32 wasn't even being listened to. the end result was that entire areas of posixmodule.c were being compiled when they shouldn't have been. later, i tried to correctly #define WIN32 (or whatever was required), only to find that the mingw32 libraries don't support many of the necessary functions. for example, it's assumed that crypto libraries exist, and many other things. all in all, it didn't go too well :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Martin v. Löwis [EMAIL PROTECTED] added the comment: So what's the status of this? Who is still interested in seeing what patches considered? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
rwmjones [EMAIL PROTECTED] added the comment: I'm very slowly working up a patch here (again 2.5.2). Since I haven't actually got even python.exe compiled yet I can't promise anything, but you never know ... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: In particular, I think that X-compiling is a common request added another one to the list. justification: pywebkitgtk cross-compiling for win32, using mingw32. i'm not paying for microsoft license fees, i'm not paying for a computer capable of running msvc, i'm not paying for the bandwidth to download msvc and/or set it up. much happier with mingw32, but mingw32 runs like an absolute dog under wine - and often wine_server hangs. (at least a 20x performance hit for running msys and mingw32 under wine). so... that leaves cross-compiling. i need the development libraries from python 2.5 in order to create a windows version of pywebkitgtk. -- nosy: +lkcl ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: the cross-compile fails on Parser/acceler.c the reason is because the included file, pyconfig.h, has #define gid_t int for use by the mingw32 compiler, which is... bad! removing gid_t from pyconfig.h bizarrely fixes the compile without.. so far.. any issues ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: pyport.h line 773 - commenting out the test for LONG_BIT != 8 * SIZEOF_LONG - we're cross-compiling amd64 host, target mingw32 - 32-bit. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: line 199 of thread_pthread.h and line 221: Python/thread_pthread.h:200: error: aggregate value used where an integer was expected hmmm... maybe this is due to me using mingw32 based on gcc 4.4.4. well, a quick #if 0 seems to fix it :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: posixmodule.c - line 2328: add this: #if ( defined(__MINGW32__) || defined(__WATCOMC__) || defined(PYCC_VACPP) ) !defined(__QNX__) res = mkdir(path); #else res = mkdir(path, mode); #endif ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: posixmodule: line 3530: #ifdef __MINGW32__ master_fd = open(DEV_PTY_FILE, O_RDWR); /* open master */ #else master_fd = open(DEV_PTY_FILE, O_RDWR | O_NOCTTY); /* open master */ #endif not sure i should be compiling posixmodule under mingw32 :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Luke Kenneth Casson Leighton [EMAIL PROTECTED] added the comment: line 6193: #if !defined(__MINGW32__) !defined(MS_WINDOWS) defined(HAVE_FCNTL_H) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Christopher Friedt added the comment: I can confirm what John Stowers experienced with ac_cv_printf_zd Did someone forget to run autoconf afterward? When I did, retrying configure again returned an error saying that config.sub was missing. I made configure just write out a yes to the ac_cv_printf_zd_format. After running 'make', the build failed saying make: *** No rule to make target `Parser/[EMAIL PROTECTED]@', needed by `Parser/[EMAIL PROTECTED]@'. Stop. -- nosy: +cfriedt _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
John Stowers added the comment: Hello, I recently tried this in combination with jhbuild, cross compiling with mingw (to built some python gtk extensions). I tried you patch against the 2.5.1 version and recieved the following error: checking for /dev/ptmx... yes checking for /dev/ptc... no checking for %zd printf() format support... configure: error: cannot run test program while cross compiling See `config.log' for more details. *** error during stage configure of python25: ## Error running ./configure --prefix /home/john/jhbuild/win32/build/ --build=i686-pc-linux-gnuaout --host=i586-pc-mingw32msvc --target=i586-pc-mingw32msvc --disable-docs --enable-all-warnings AR=/usr/bin/i586-mingw32msvc-ar RANLIB=/usr/bin/i586-mingw32msvc-ranlib STRIP=/usr/bin/i586-mingw32msvc-strip AS=/usr/bin/i586-mingw32msvc-as DLLTOOL=/usr/bin/i586-mingw32msvc-dlltool OBJDUMP=/usr/bin/i586-mingw32msvc-objdump NM=/usr/bin/i586-mingw32msvc-nm WINDRES=/usr/bin/i586-mingw32msvc-windres *** [1/1] I noticed that the other reference for cross compiling pthon 2.5 at http://whatschrisdoing.com/blog/2006/10/06/howto-cross-compile-python-25/ patched this check out -- nosy: +nzjrs _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
John Stowers added the comment: Sorry, I should have clarified further in my last comment. Looking over the configure script I don't recognize the %zd test as one that could be circumvented by supplying a config.cache file with the appropriate values. How do I escape this limitation? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Scott Tsai added the comment: John, set ac_cv_printf_zd_format. In general, read the configure.in source. On Dec 10, 2007 1:17 PM, John Stowers [EMAIL PROTECTED] wrote: John Stowers added the comment: Sorry, I should have clarified further in my last comment. Looking over the configure script I don't recognize the %zd test as one that could be circumvented by supplying a config.cache file with the appropriate values. How do I escape this limitation? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 _ _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1597850 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Scott Tsai added the comment:
I messed up while generating cross-2.5.1.patch last time.
Added a hackish way to set disabled_module_list in setup.py from
corresponding environment variable.
Added file: http://bugs.python.org/file8628/cross-2.5.1.patch
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1597850
_diff --exclude=configure -urN Python-2.5.1/configure.in Python-2.5.1-hacked/configure.in
--- Python-2.5.1/configure.in 2007-03-12 18:50:51.0 +0800
+++ Python-2.5.1-hacked/configure.in 2007-10-27 14:31:18.0 +0800
@@ -9,6 +9,11 @@
AC_CONFIG_SRCDIR([Include/object.h])
AC_CONFIG_HEADER(pyconfig.h)
+# find compiler while respecting --host setting
+AC_CANONICAL_HOST()
+AC_CHECK_TOOLS(CC,gcc cc)
+AC_CHECK_TOOLS(CXX,g++ c++)
+
dnl This is for stuff that absolutely must end up in pyconfig.h.
dnl Please use pyport.h instead, if possible.
AH_TOP([
@@ -163,8 +168,8 @@
# Set name for machine-dependent library files
AC_SUBST(MACHDEP)
AC_MSG_CHECKING(MACHDEP)
-if test -z $MACHDEP
-then
+if test -z $MACHDEP; then
+if test $cross_compiling = no; then
ac_sys_system=`uname -s`
if test $ac_sys_system = AIX -o $ac_sys_system = Monterey64 \
-o $ac_sys_system = UnixWare -o $ac_sys_system = OpenUNIX; then
@@ -172,6 +177,23 @@
else
ac_sys_release=`uname -r`
fi
+else
+ m=`$CC -dumpmachine`
+ changequote(, )#dnl
+ ac_sys_system=`expr $m : [^-]*-\([^-]*\)`
+ changequote([, ])#dnl
+
+
+ case $ac_sys_system in
+ cygwin*) ac_sys_system=`echo $ac_sys_system | sed s/cygwin/CYGWIN/g `;;
+ darwin*) ac_sys_system=`echo $ac_sys_system | sed s/darwin/Darwin/g `;;
+ freebsd*) ac_sys_system=`echo $ac_sys_system | sed s/freebsd/FreeBSD/g `;;
+ linux*) ac_sys_system=`echo $ac_sys_system | sed s/linux/Linux/g `;;
+ esac
+
+
+fi
+
ac_md_system=`echo $ac_sys_system |
tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'`
ac_md_release=`echo $ac_sys_release |
@@ -419,8 +441,8 @@
if test -z $CXX
then
case $CC in
-gcc)AC_PATH_PROG(CXX, [g++], [g++], [notfound]) ;;
-cc) AC_PATH_PROG(CXX, [c++], [c++], [notfound]) ;;
+gcc)AC_CHECK_TOOL(CXX, [g++], [notfound]) ;;
+cc) AC_CHECK_TOOL(CXX, [c++], [notfound]) ;;
esac
if test $CXX = notfound
then
@@ -429,7 +451,7 @@
fi
if test -z $CXX
then
- AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
+ AC_CHECK_TOOLS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
if test $CXX = notfound
then
CXX=
@@ -480,9 +502,11 @@
then
AC_MSG_RESULT(yes)
BUILDEXEEXT=.exe
+case_sensitive=no
else
- AC_MSG_RESULT(no)
- BUILDEXEEXT=$EXEEXT
+AC_MSG_RESULT(no)
+BUILDEXEEXT=$EXEEXT
+case_sensitive=yes
fi
rmdir CaseSensitiveTestDir
@@ -681,9 +705,9 @@
AC_MSG_RESULT($LDLIBRARY)
-AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR, ar aal, ar)
+# find tools while respecting --host setting
+AC_CHECK_TOOL(RANLIB,ranlib)
+AC_CHECK_TOOLS(AR,ar aal,ar)
AC_SUBST(SVNVERSION)
AC_CHECK_PROG(SVNVERSION, svnversion, found, not-found)
@@ -801,7 +825,7 @@
AC_TRY_RUN([int main() { return 0; }],
ac_cv_no_strict_aliasing_ok=yes,
ac_cv_no_strict_aliasing_ok=no,
- ac_cv_no_strict_aliasing_ok=no)
+ ac_cv_no_strict_aliasing_ok=yes)
CC=$ac_save_cc
AC_MSG_RESULT($ac_cv_no_strict_aliasing_ok)
if test $ac_cv_no_strict_aliasing_ok = yes
@@ -3345,30 +3369,19 @@
AC_MSG_RESULT(no)
)
-AC_MSG_CHECKING(for /dev/ptmx)
-
-if test -r /dev/ptmx
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTMX, 1,
- [Define if we have /dev/ptmx.])
-else
- AC_MSG_RESULT(no)
-fi
-
-AC_MSG_CHECKING(for /dev/ptc)
-
-if test -r /dev/ptc
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTC, 1,
- [Define if we have /dev/ptc.])
-else
- AC_MSG_RESULT(no)
-fi
+AC_CHECK_FILE(/dev/ptmx,
+ [AC_DEFINE(HAVE_DEV_PTMX, 1,
+ [Define if we have /dev/ptmx.])],
+ [])
+
+AC_CHECK_FILE(/dev/ptc,
+ [AC_DEFINE(HAVE_DEV_PTC, 1,
+ [Define if we have /dev/ptc.])],
+ [])
AC_MSG_CHECKING(for %zd printf() format support)
-AC_TRY_RUN([#include stdio.h
+AC_CACHE_VAL(ac_cv_printf_zd_format,
+ AC_TRY_RUN([#include stdio.h
#include stddef.h
#include string.h
@@ -3400,7 +3413,7 @@
}],
[AC_MSG_RESULT(yes)
AC_DEFINE(PY_FORMAT_SIZE_T, z, [Define to printf format modifier for Py_ssize_t])],
- AC_MSG_RESULT(no))
+ AC_MSG_RESULT(no)))
AC_CHECK_TYPE(socklen_t,,
AC_DEFINE(socklen_t,int,
@@ -3430,6 +3443,63 @@
done
AC_MSG_RESULT(done)
+# Cross compiling
+AC_SUBST(cross_compiling)
+
+if test $cross_compiling = yes; then
+AC_MSG_CHECKING(cc for build)
+CC_FOR_BUILD=${CC_FOR_BUILD-cc}
+else
+CC_FOR_BUILD=${CC_FOR_BUILD-$CC}
+fi
+
+if test $cross_compiling = yes; then
+ AC_MSG_RESULT($CC_FOR_BUILD)
+fi
+
+AC_ARG_VAR(CC_FOR_BUILD,[build system C compiler (default: cc)])
+
+if test $cross_compiling = yes; then
+AC_MSG_CHECKING(python for build)
+
[issue1597850] Cross compiling patches for MINGW
Scott Tsai added the comment:
Grumble, uploaded wrong version of patch.
Added file: http://bugs.python.org/file8629/cross-2.5.1.patch
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1597850
_diff -urN --exclude configure --exclude 'config.*' Python-2.5.1/configure.in Python-2.5.1-hacked/configure.in
--- Python-2.5.1/configure.in 2007-03-12 18:50:51.0 +0800
+++ Python-2.5.1-hacked/configure.in 2007-10-27 16:46:39.0 +0800
@@ -9,6 +9,11 @@
AC_CONFIG_SRCDIR([Include/object.h])
AC_CONFIG_HEADER(pyconfig.h)
+# find compiler while respecting --host setting
+AC_CANONICAL_HOST()
+AC_CHECK_TOOLS(CC,gcc cc)
+AC_CHECK_TOOLS(CXX,g++ c++)
+
dnl This is for stuff that absolutely must end up in pyconfig.h.
dnl Please use pyport.h instead, if possible.
AH_TOP([
@@ -163,8 +168,8 @@
# Set name for machine-dependent library files
AC_SUBST(MACHDEP)
AC_MSG_CHECKING(MACHDEP)
-if test -z $MACHDEP
-then
+if test -z $MACHDEP; then
+if test $cross_compiling = no; then
ac_sys_system=`uname -s`
if test $ac_sys_system = AIX -o $ac_sys_system = Monterey64 \
-o $ac_sys_system = UnixWare -o $ac_sys_system = OpenUNIX; then
@@ -172,6 +177,23 @@
else
ac_sys_release=`uname -r`
fi
+else
+ m=`$CC -dumpmachine`
+ changequote(, )#dnl
+ ac_sys_system=`expr $m : [^-]*-\([^-]*\)`
+ changequote([, ])#dnl
+
+
+ case $ac_sys_system in
+ cygwin*) ac_sys_system=`echo $ac_sys_system | sed s/cygwin/CYGWIN/g `;;
+ darwin*) ac_sys_system=`echo $ac_sys_system | sed s/darwin/Darwin/g `;;
+ freebsd*) ac_sys_system=`echo $ac_sys_system | sed s/freebsd/FreeBSD/g `;;
+ linux*) ac_sys_system=`echo $ac_sys_system | sed s/linux/Linux/g `;;
+ esac
+
+
+fi
+
ac_md_system=`echo $ac_sys_system |
tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'`
ac_md_release=`echo $ac_sys_release |
@@ -419,8 +441,8 @@
if test -z $CXX
then
case $CC in
-gcc)AC_PATH_PROG(CXX, [g++], [g++], [notfound]) ;;
-cc) AC_PATH_PROG(CXX, [c++], [c++], [notfound]) ;;
+gcc)AC_CHECK_TOOL(CXX, [g++], [notfound]) ;;
+cc) AC_CHECK_TOOL(CXX, [c++], [notfound]) ;;
esac
if test $CXX = notfound
then
@@ -429,7 +451,7 @@
fi
if test -z $CXX
then
- AC_CHECK_PROGS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
+ AC_CHECK_TOOLS(CXX, $CCC c++ g++ gcc CC cxx cc++ cl, notfound)
if test $CXX = notfound
then
CXX=
@@ -480,9 +502,11 @@
then
AC_MSG_RESULT(yes)
BUILDEXEEXT=.exe
+case_sensitive=no
else
- AC_MSG_RESULT(no)
- BUILDEXEEXT=$EXEEXT
+AC_MSG_RESULT(no)
+BUILDEXEEXT=$EXEEXT
+case_sensitive=yes
fi
rmdir CaseSensitiveTestDir
@@ -681,9 +705,9 @@
AC_MSG_RESULT($LDLIBRARY)
-AC_PROG_RANLIB
-AC_SUBST(AR)
-AC_CHECK_PROGS(AR, ar aal, ar)
+# find tools while respecting --host setting
+AC_CHECK_TOOL(RANLIB,ranlib)
+AC_CHECK_TOOLS(AR,ar aal,ar)
AC_SUBST(SVNVERSION)
AC_CHECK_PROG(SVNVERSION, svnversion, found, not-found)
@@ -801,7 +825,7 @@
AC_TRY_RUN([int main() { return 0; }],
ac_cv_no_strict_aliasing_ok=yes,
ac_cv_no_strict_aliasing_ok=no,
- ac_cv_no_strict_aliasing_ok=no)
+ ac_cv_no_strict_aliasing_ok=yes)
CC=$ac_save_cc
AC_MSG_RESULT($ac_cv_no_strict_aliasing_ok)
if test $ac_cv_no_strict_aliasing_ok = yes
@@ -3345,30 +3369,19 @@
AC_MSG_RESULT(no)
)
-AC_MSG_CHECKING(for /dev/ptmx)
-
-if test -r /dev/ptmx
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTMX, 1,
- [Define if we have /dev/ptmx.])
-else
- AC_MSG_RESULT(no)
-fi
-
-AC_MSG_CHECKING(for /dev/ptc)
-
-if test -r /dev/ptc
-then
- AC_MSG_RESULT(yes)
- AC_DEFINE(HAVE_DEV_PTC, 1,
- [Define if we have /dev/ptc.])
-else
- AC_MSG_RESULT(no)
-fi
+AC_CHECK_FILE(/dev/ptmx,
+ [AC_DEFINE(HAVE_DEV_PTMX, 1,
+ [Define if we have /dev/ptmx.])],
+ [])
+
+AC_CHECK_FILE(/dev/ptc,
+ [AC_DEFINE(HAVE_DEV_PTC, 1,
+ [Define if we have /dev/ptc.])],
+ [])
AC_MSG_CHECKING(for %zd printf() format support)
-AC_TRY_RUN([#include stdio.h
+AC_CACHE_VAL(ac_cv_printf_zd_format,
+ AC_TRY_RUN([#include stdio.h
#include stddef.h
#include string.h
@@ -3400,7 +3413,7 @@
}],
[AC_MSG_RESULT(yes)
AC_DEFINE(PY_FORMAT_SIZE_T, z, [Define to printf format modifier for Py_ssize_t])],
- AC_MSG_RESULT(no))
+ AC_MSG_RESULT(no)))
AC_CHECK_TYPE(socklen_t,,
AC_DEFINE(socklen_t,int,
@@ -3430,6 +3443,63 @@
done
AC_MSG_RESULT(done)
+# Cross compiling
+AC_SUBST(cross_compiling)
+
+if test $cross_compiling = yes; then
+AC_MSG_CHECKING(cc for build)
+CC_FOR_BUILD=${CC_FOR_BUILD-cc}
+else
+CC_FOR_BUILD=${CC_FOR_BUILD-$CC}
+fi
+
+if test $cross_compiling = yes; then
+ AC_MSG_RESULT($CC_FOR_BUILD)
+fi
+
+AC_ARG_VAR(CC_FOR_BUILD,[build system C compiler (default: cc)])
+
+if test $cross_compiling = yes; then
+AC_MSG_CHECKING(python for build)
+PYTHON_FOR_BUILD=${PYTHON_FOR_BUILD-python}
+PYTHON_FOR_BUILD=`which $PYTHON_FOR_BUILD`
+else
+
