[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Steve Dower added the comment: Doesn't seem to be anything left to do here, so closing as fixed. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker __

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Jan Harkes added the comment: @Carl.Kleffner: that is an interesting message but it discusses using binutils(/mingw?) generated import libraries with the MS linker. This bugreport was about two 64-bit objects that were accidentally included in an otherwise 32-bit library and it has been resolv

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Carl Kleffner added the comment: I experienced this behaviour by accident several times. Most likely this is due to inconsistenticies in different binutils and mingw-runtime versions/patches. See i.e. http://article.gmane.org/gmane.comp.gnu.binutils/46799 A robust solution is to exclusively use

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Benjamin Gilbert added the comment: Is there any reason an import library generated by a particular MinGW version shouldn't be usable by any other MinGW version? -- ___ Python tracker _

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Carl Kleffner added the comment: The most robust way to support a specific mingw-w64 distribution is to copy a python import library generated by this specific toolchain and the provided import library for the corresponding msvcrXX.dll runtime into the libs folder. This has to be performed by t

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Paul Moore added the comment: I'm still somewhat confused as to why we're looking at this in the context of manually building an extension. It's *certainly* true that anyone attempting to build a Python extension by hand (as per Matthew Barnett's instructions) should be able and willing to bui

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Benjamin Gilbert added the comment: Zachary: gendef is an auxiliary tool; I'm not sure a basic installation of MinGW-w64 will have it. However, I've checked Cygwin and Fedora (my two points of reference) and a gendef package is available in both. -- __

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Matthew Barnett added the comment: @steve.dower: Yes. For Python 35, it appears that it'll link to libpython??.a or python??.dll, whichever it finds in the given folder, so it doesn't actually need libpython??.a anymore. Which is nice. :-) -- ___ P

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Zachary Ware added the comment: If I'm not mistaken, if you're building an extension with some flavor of MinGW, you've got the tools to build the lib yourself, right? It strikes me as being much more reliable to provide hints towards how to do it yourself than to provide a binary for somethin

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Roundup Robot added the comment: New changeset 686f9a607b98 by Steve Dower in branch '2.7': Issue 24385: Adds "--as-flags=--32" when generating 32-bit MinGW library. https://hg.python.org/cpython/rev/686f9a607b98 -- ___ Python tracker

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Roundup Robot added the comment: New changeset e4cde2f928fe by Steve Dower in branch '3.5': Issue 24385: Adds "--as-flags=--32" when generating 32-bit MinGW library. https://hg.python.org/cpython/rev/e4cde2f928fe New changeset 5fa77372e675 by Steve Dower in branch 'default': Issue 24385: Adds "-

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Steve Dower added the comment: Ah, I misread msg244875 and thought it was still requiring different tools. I'll add that option in for the next release then, and if there are still issues I'll come back to removing the libraries. -- ___ Python track

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Benjamin Gilbert added the comment: Steve, I don't think that's the right characterization of this bug. Putting 64-bit .o files in a 32-bit import library seems wrong for both MinGW and MinGW-w64. msg244874 says that if you use the dlltool from the *32-bit* MinGW-w64 to build the 32-bit impo

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Jan Harkes added the comment: Just noticed in Matthew Barnett's comment that he has an additional "--as-flags=--32" argument. x86_64-w64-mingw32-dlltool --as-flags=--32 --dllname python27.dll --def mingwlib.def --output-lib win32\libpython27.a -m i386 Creates a correct libpython27.a where e

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Jan Harkes added the comment: The Python-2.7.9 version of the Windows-x86 MSI installed version works fine with the 32-bit mingw. In fact I rolled back to that release and built my code successfully. Somehow the fix for https://bugs.python.org/issue23199 must have broken the 32-bit libpython2

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Matthew Barnett added the comment: Here's how I can build the regex module on Windows 8.1, 64-bit, using only MinGW64. For Python 3.5, I can link against "python35.dll", but for earlier versions, including Python 2.7, I need "libpython??.a". I have built regex module for all of the 16 support

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Changes by R. David Murray : -- nosy: +paul.moore ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Steve Dower added the comment: Given I can't generate the file any other way that will be compatible for everyone, unless someone contributes a fix I'm going to stop shipping these files and let people generate them using whatever tools they have. If anyone wants to suggest instructions then I

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Changes by Benjamin Gilbert : -- nosy: +bgilbert ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

Changes by Zachary Ware : -- assignee: -> steve.dower components: +Build, Installation, Windows -Library (Lib) nosy: +steve.dower, tim.golden, zach.ware ___ Python tracker ___ _

[issue24385] libpython27.a in python-2.7.10 i386 (windows msi release) contains 64-bit objects

New submission from Jan Harkes: mingw32 fails to link with libpython27.a fails with the following error /cygdrive/C/Python27/libs/libpython27.a: error adding symbols: File format not recognized extracting all the objects from libpython27.a and checking them with objdump shows that two objects