Steve Dower added the comment:
Yep
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23199
___
___
Python-bugs-list
Zachary Ware added the comment:
Steve: is this fixed and ready for next time?
--
resolution: - fixed
stage: - resolved
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23199
Daniel Franke added the comment:
I've downloaded and installed python-2.7.9.amd.msi and spent some hours trying
to understand the myriad of i386/x86-64 related linker errors I get when
attempting to build an extension module. Now that I found this report I can at
least stop doubting my
Steve Dower added the comment:
I posted these commands above (modulo version number). If you have MinGW and
binutils then it should Just Work, but I'm not very experienced with the range
of installations you could have, so you may need to track down the gendef and
dlltool tools:
gendef -
Roundup Robot added the comment:
New changeset 536a816e7232 by Steve Dower in branch '2.7':
Issue #23199: libpython27.a in amd64 release is 32-bit
https://hg.python.org/cpython/rev/536a816e7232
--
nosy: +python-dev
___
Python tracker
Steve Dower added the comment:
It looks like #1088716 is where the change was made a bit over 10 years ago.
Adding Paul to see if he has any further insight, but I'm pretty sure at that
point there was no 64-bit Python (there certainly wasn't a 64-bit Windows that
people were using), and
Paul Moore added the comment:
There's a lot of politics around the mingw vs mingw64 situation, but in
practice I believe the various mingw64 builds are fine. So I see no reason not
to supply a correct 64-bit libpythonXY.a.
When the patch was made to include the libpythonXY.a file to the msi
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
Steve Dower added the comment:
Just came across this advice on
https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows:
Do not use MinGW-w64. As you will notice, the MinGW import library for
Python (e.g. libpython27.a) is omitted from the AMD64 version of
Python. This is
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
Steve Dower added the comment:
So I've grabbed gendef and dlltool from the latest mingw-w64 and will look at
using those in the future for both 2.7 and 3.5.
According to objdump, I can use these to create file format pe-i386 and
pe-x86-64 with the same tools. Are these the correct formats for
Steve Dower added the comment:
Is the libpython27.a file actually a 32-bit version or is it just corrupted? It
seems to be considerably smaller than the version in the 32-bit installer, but
it is certainly not being generated from the 32-bit version.
I didn't write this code originally, and I
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
Steve Dower added the comment:
Thanks for the notice. I'll try and get that fixed up for the next 2.7 release.
--
assignee: - steve.dower
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23199
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
15 matches
Mail list logo
