You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
wininst regression: errors when building on linux #53200
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/merwok'closed_at=<Date2021-02-03.18:37:38.872>created_at=<Date2010-06-09.14:20:42.724>labels= ['type-bug', 'library']
title='wininst regression: errors when building on linux'updated_at=<Date2021-02-03.18:37:38.872>user='https://bugs.python.org/techtonik'
2.5.1 version of distutils was able to correctly build wininst dists from linux. Right now there are errors which I'll describe in more details once I can get some Linux box.
At least is was reported that compiled binaries contains wrong platform name, i.e. 'linux' and there are errors about inability to look up some compiler options in windows registry while building.
The error comes from the msvccompiler module, which shouldn’t get used on non-Windows platforms unless I’m mistaken. Reading the module, I’m not sure at all this command was meant to be run on not-Windows OSes.
techtonik commented on Jun 11, 2010
techtonikmannequin
MannequinAuthor
More actions
It did run ok on non-Windows OSes with previous Python versions.
It certainly should be possible to build these installers, and if I understand your output correctly, an installer *was* built. The warning is, after all, just a warning, and probably just the warning got added compared to 2.5, but the behavior is the same.
The platform name is a regression though.
techtonik commented on Jul 11, 2010
techtonikmannequin
MannequinAuthor
More actions
The regression is two-fold:
platform name regression is caused by r62197 by Mark Hammond - Issue bpo-2513: enable 64bit cross compilation on windows
when wininst stub selection started to depend on MSVC compiler version is yet to be investigated, but I am sure that wininst stub selection should only be affected by compatibility with operating system only
I get an error trying to run the command because of the use of the mbcs codec.
Ezio made some comments on Rietveld, I addressed them in a local clone.
Question for Windows users/experts: Do the terms “binary extension” and “binary code” make sense? If not, I can change them to the clearer “extension modules” and “C code”.
I opened another bug for the MBCS problem which prevents me from testing Anatoly’s patch.
runtux commented on May 13, 2011
runtuxmannequin
Mannequin
More actions
2.6 already produces a .linux-i686.exe package instead of .win32.exe when running bdist_wininst. I've now used python2.5 for producing a binary windows installer for roundup.
Sean: In msg135902 I am merely explaining why I removed 2.6 from the list of versions. Only 2.7, 3.2 and 3.3 can get fixed.
If you look at my previous message or the list of dependencies, you can see that bpo-10945 needs to be fixed first before I can review the patch provided for this issue.
+ if (not self.distribution.has_ext_modules() and
+ not self.distribution.has_c_libraries()):
+ basename = "%s.%s" % (fullname, "win32")
I feel it may be better to insert plat_name there if it exists. That way, users can create installers targeted for win-amd64. Why is this needed for a pure python packages? This bug: http://bugs.python.org/issue6792
Distutils is now deprecated (see PEP-632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools
Activity
techtonik commentedon Jun 9, 2010
2.5.1 version of distutils was able to correctly build wininst dists from linux. Right now there are errors which I'll describe in more details once I can get some Linux box.
techtonik commentedon Jun 9, 2010
At least is was reported that compiled binaries contains wrong platform name, i.e. 'linux' and there are errors about inability to look up some compiler options in windows registry while building.
briancurtin commentedon Jun 9, 2010
Where was that reported?
techtonik commentedon Jun 9, 2010
In this SCons thread http://scons.tigris.org/ds/viewMessage.do?dsForumId=1268&dsMessageId=2617686
techtonik commentedon Jun 11, 2010
merwok commentedon Jun 11, 2010
The error comes from the msvccompiler module, which shouldn’t get used on non-Windows platforms unless I’m mistaken. Reading the module, I’m not sure at all this command was meant to be run on not-Windows OSes.
techtonik commentedon Jun 11, 2010
It did run ok on non-Windows OSes with previous Python versions.
birkenfeld commentedon Jun 27, 2010
It certainly should be possible to build these installers, and if I understand your output correctly, an installer *was* built. The warning is, after all, just a warning, and probably just the warning got added compared to 2.5, but the behavior is the same.
The platform name is a regression though.
techtonik commentedon Jul 11, 2010
The regression is two-fold:
platform name regression is caused by r62197 by Mark Hammond - Issue bpo-2513: enable 64bit cross compilation on windows
when wininst stub selection started to depend on MSVC compiler version is yet to be investigated, but I am sure that wininst stub selection should only be affected by compatibility with operating system only
More complete research notes are at https://wave.google.com/wave/waveref/googlewave.com/w+GnQ9tjc8A
techtonik commentedon Jul 12, 2010
http://codereview.appspot.com/1774043
birkenfeld commentedon Jul 12, 2010
Did you test that patch? ISTM that it contains a syntax error:
+ if not self.distribution.has_ext_modules()
+ and not self.distribution.has_c_libraries():
techtonik commentedon Jul 12, 2010
reuploaded correct version to rietveld.
1 remaining item
birkenfeld commentedon Oct 15, 2010
Raising priority.
merwok commentedon Oct 18, 2010
I get an error trying to run the command because of the use of the mbcs codec.
Ezio made some comments on Rietveld, I addressed them in a local clone.
Question for Windows users/experts: Do the terms “binary extension” and “binary code” make sense? If not, I can change them to the clearer “extension modules” and “C code”.
techtonik commentedon Jan 9, 2011
Fixed Ezio comments at http://codereview.appspot.com/1774043
Eric, if I understand you correctly, the mbcs issue you're experiencing is unrelated to the patch. What else do you need?
techtonik commentedon Jan 19, 2011
Is this issue really critical?
Bump.
merwok commentedon Jan 19, 2011
I opened another bug for the MBCS problem which prevents me from testing Anatoly’s patch.
runtux commentedon May 13, 2011
2.6 already produces a .linux-i686.exe package instead of .win32.exe when running bdist_wininst. I've now used python2.5 for producing a binary windows installer for roundup.
merwok commentedon May 13, 2011
2.6 only gets security fixes.
jafo commentedon Mar 13, 2012
Éric: In http://bugs.python.org/issue8954#msg135902 are you saying:
This issue needs to be re-targeted to a newer Python.
Close -- won't fix.
Something else?
This issue seems to be stuck here, any ideas on what needs to be done to move this forward?
merwok commentedon Mar 13, 2012
Sean: In msg135902 I am merely explaining why I removed 2.6 from the list of versions. Only 2.7, 3.2 and 3.3 can get fixed.
If you look at my previous message or the list of dependencies, you can see that bpo-10945 needs to be fixed first before I can review the patch provided for this issue.
AaronStaley commentedon May 22, 2012
I was looking over this patch (as it relates to my bug report: http://bugs.python.org/issue14877?@ok_message=msg%20161314%20created%3Cbr%3Eissue%2014877%20message_count%2C%20messages%20edited%20ok&@template=item) and noticed that this line:
+ if (not self.distribution.has_ext_modules() and
+ not self.distribution.has_c_libraries()):
+ basename = "%s.%s" % (fullname, "win32")
I feel it may be better to insert plat_name there if it exists. That way, users can create installers targeted for win-amd64. Why is this needed for a pure python packages? This bug: http://bugs.python.org/issue6792
zooba commentedon Feb 3, 2021
Distutils is now deprecated (see PEP-632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools