[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 ___ ___

[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 ? --

[issue1597850] Cross compiling patches for MINGW

Changes by Gregory P. Smith : -- nosy: -gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue1597850] Cross compiling patches for MINGW

Changes by wrobell : -- nosy: +wrobell ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue1597850] Cross compiling patches for MINGW

Changes by Éric Araujo : -- versions: +Python 3.3 -3rd party, Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue1597850] Cross compiling patches for MINGW

Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue1597850] Cross compiling patches for MINGW

Changes by Éric Araujo : -- versions: +3rd party ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue1597850] Cross compiling patches for MINGW

Roumen Petrov 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 ex

[issue1597850] Cross compiling patches for MINGW

Martin v. Löwis 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 actu

[issue1597850] Cross compiling patches for MINGW

Éric Araujo 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 ___ __

[issue1597850] Cross compiling patches for MINGW

Amaury Forgeot d'Arc added the comment: > the changes are small which patch are you referring to? They look quite large to me. -- nosy: +amaury.forgeotdarc ___ Python tracker

[issue1597850] Cross compiling patches for MINGW

Éric Araujo 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 co

[issue1597850] Cross compiling patches for MINGW

Mark Lawrence added the comment: I understand that cross-compilation is not supported so this must now be aimed at 3.2. -- nosy: +BreamoreBoy versions: +Python 3.2 -Python 2.6 ___ Python tracker ___

[issue1597850] Cross compiling patches for MINGW

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue1597850] Cross compiling patches for MINGW

Joshua Kinard 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/con

[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]>

[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-

[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

[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

[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 t

[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

[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 bin

[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 tra

[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

[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/libp

[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.

[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]>

[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]> ___

[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

[issue1597850] Cross compiling patches for MINGW

rwmjones <[EMAIL PROTECTED]> added the comment: I'm trying to use this patch to cross-compile Python under Fedora, using the Fedora-MinGW project (http://fedoraproject.org/wiki/MinGW) IMHO the documentation is confusing. It sounds from the docs like CC_FOR_BUILD should be the native system comp

[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]>

[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 posix

[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

[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 f

[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]>

[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

[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 c

[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_pri

[issue1597850] Cross compiling patches for MINGW

John Stowers added the comment: I created config.cache and populated it with ac_cv_printf_zd_format=yes before executing the following ./configure --prefix /home/john/jhbuild/win32/build/ --build=i686-pc-linux-gnuaout --host=i586-pc-mingw32msvc --target=i586-pc-mingw32msvc --disable-docs --e

[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 confi

[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? __

[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 ch

[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]> _diff -urN --exclude

[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 _ Trac