[issue23199] libpython27.a in amd64 release is 32-bit
Zach Welch added the comment: That's certainly an interesting data point. We are just beginning to use MinGW-w64 internally, so I do not have enough experience to confirm or deny that advice. For various reasons, we must use cross-compiling on a Linux host, so the advice to use a native compiler is moot for our situation. Certainly, documenting the absense of the 64-bit library would be good. Providing a documented script to generate one is better. Providing the library would be ideal, if there will not be forward compatibility or runtime issues. It would be nice to see concrete details about the current state of affairs. The cython project's warning would carry more weight with me if it contained links to specific details: mailing list discussion that led to the deliberate decision to omit the 64-bit library, bug reports filed against the mingw-w64 project about the runtime issues, etc.. That said, such details probably do exist, but my cursory searching has failed to turn them up. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23199] libpython27.a in amd64 release is 32-bit
Zach Welch added the comment: Yes, pe-i386 and pe-x86-64 are the respective 32-bit and 64-bit object formats. Your commands seem reasonable. With gendef, I just let it create a .def file with the same name (i.e. skip the '-' and redirection); in my mind, that reinforces the association between the dll and def files. With dlltool, I did not have to use the -m flag (as x86-64 is the default for me), but I don't see anything wrong with being explicit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23199] libpython27.a in amd64 release is 32-bit
Zach Welch added the comment: The libpython27.a is an actual 32-bit version, as confirmed by running objdump -t on it. It reports the sections' file format as pe-i386 instead of pe-x86-64. I am only using it for building for the 64-bit target, so I cannot confirm its viability for 32-bit builds. To build 64-bit Windows binaries, you need a MinGW-w64 toolchain (which is a completely separate project from the original MinGW project). The target triplet is x86_64-w64-mingw32. I cannot speak to the stability of the MinGW-w64 library interface, but I would expect it to be stable. To wit, I would be shocked if future changes required regeneration of third-party .a files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23199] libpython27.a in amd64 release is 32-bit
New submission from Zach Welch: I tried to link a program against the libpython27.a provided by the latest 2.7.9 amd64 installer, only to discover that the provided library is a 32-bit version. I had to go through the gendef/dlltool dance in order to produce a useable 64-bit library from the DLL. -- components: Library (Lib), Windows messages: 233702 nosy: steve.dower, tim.golden, zach.ware, zwelch priority: normal severity: normal status: open title: libpython27.a in amd64 release is 32-bit type: compile error versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
