Thomas Heller thel...@ctypes.org added the comment:
I'm not sure this issue is really done. The current state works fine, but
there is one problem remaining:
There are Python extensions that seem to need a manifest pointing to the MSVC
runtime libs: dlls that start in-process com servers,
egaudry e...@fft.be added the comment:
Hi Thomas,
I think we should open a new issue (child from issue 4120), just to make
sure the whole thing remains understandable.
Regards,
Eloi
Thomas Heller wrote:
Thomas Heller thel...@ctypes.org added the comment:
I'm not sure this issue is really
Christoph Gohlke cgoh...@uci.edu added the comment:
I mentioned the problem with pythoncom.dll and suggested a solution in
issue7833.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
Martin v. Löwis mar...@v.loewis.de added the comment:
First question: Open a new issue, or discuss it in this one (and repoen it)?
Please open a new issue. AFAICT, the original issues request (do not
embed manifests in pyd files) is now implemented fully. Feel free to
leave a link to the new
Sridhar Ratnakumar sridh...@activestate.com added the comment:
See issue 7556 for the can't use a string pattern on a bytes-like object
error.
--
nosy: +srid
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
Stefan Krah stefan-use...@bytereef.org added the comment:
With the latest Python3.1 svn version of msvc9compiler.py, I get a
can't use a string pattern on a bytes-like object error. The
attached diff fixes the error.
--
nosy: +skrah
versions: +Python 3.1 -Python 2.6, Python 2.7, Python
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. Committed as r76651, r76652, r76653, r76654,
r76655 and r76656.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
___
egaudry e...@fft.be added the comment:
I came across this (very) interesting thread after experiencing some
redistribution issue with a python(2.6)-based package built with msvc9
compiler.
I used to struggled with the SxS Microsoft policy in the past. After I
finally went for the private
Marc-Andre Lemburg m...@egenix.com added the comment:
Christoph Gohlke wrote:
Christoph Gohlke cgoh...@uci.edu added the comment:
Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
for MinGW users. The following C program is using the Python C API to
import the
Christoph Gohlke cgoh...@uci.edu added the comment:
My last comment was merely reporting that this patch can break MinGW
based build processes. It did surprise some developers that their
programs embedding matplotlib, which is now build with the MSVC9 patch,
stopped working.
--
Koen van de Sande k...@tibed.net added the comment:
The MinGW breakage probably comes from the same issue as encountered
in http://bugs.python.org/issue4120#msg80908 and #msg80909: the main
application, which embeds Matplotlib, does not have a manifest for the
MSVCR9 runtimes? That's a problem
Christoph Gohlke cgoh...@uci.edu added the comment:
Apparently the msvc9compiler_stripruntimes_regexp2 patch causes problems
for MinGW users. The following C program is using the Python C API to
import the testpyd extension generated by testpyd.py. When compiled with
MinGW, the program fails
Christoph Gohlke cgoh...@uci.edu added the comment:
There are two levels of testing.
First, on a Windows development system with Visual Studio 2008, Python
2.6.2+, and the msvc9compiler_stripruntimes_regexp2.diff patch applied,
verify that the embedded manifest in distutil generated PYD
Martin v. Löwis mar...@v.loewis.de added the comment:
What's a procedure for testing this patch (please be as precise as
possible)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
___
Nick Touran n...@partofthething.com added the comment:
Just to share my recent experience with this issue: I was attempting to
get Python 2.6 working with py4mpi, matplotlib, and pymssql on a 64-bit
Windows Vista based HPC cluster via x-copy deployment without the charm
of administrative
Koen van de Sande k...@tibed.net added the comment:
It may actually be enough to just place the
Microsoft.VC90.CRT.manifest file into the Python folder (the one with
python.exe and the CRT DLLs).
I concur with what Christoph says, that is how the embedded
installation works. However, the
Marc-Andre Lemburg m...@egenix.com added the comment:
Looking at the description of manifest files, it appears that just
removing the assemblyIdentity-element results in an invalid manifest file:
http://msdn.microsoft.com/en-us/library/aa374219(VS.85).aspx
It appears that the entire
Christoph Gohlke cgoh...@uci.edu added the comment:
This patch also removes empty dependentAssembly elements after removing
the VC.CRT assemblyIdentity element.
It seems not enough to just place the Microsoft.VC90.CRT.manifest and VC
runtime DLL files into the Python folder. On a system without
Koen van de Sande k...@tibed.net added the comment:
Thanks Christoph, those are two important fixes to the patch. I'm +1 on
having this in the next 2.6 maintenance release.
--
___
Python tracker rep...@bugs.python.org
Marc-Andre Lemburg m...@egenix.com added the comment:
Just a note on the style of the msvc9compiler_stripruntimes_revised.diff
patch:
* please try to use lines with at most 80 chars only
* it would be better to use regexps to do the searchreplace and
perhaps add wildcards to catch future
Christoph Gohlke cgoh...@uci.edu added the comment:
The attached patch uses a regular expression.
--
Added file:
http://bugs.python.org/file15072/msvc9compiler_stripruntimes_regexp.diff
___
Python tracker rep...@bugs.python.org
Marc-Andre Lemburg m...@egenix.com added the comment:
Christoph Gohlke wrote:
Christoph Gohlke cgoh...@uci.edu added the comment:
The attached patch uses a regular expression.
Much better, thanks.
--
title: Do not embed manifest files in *.pyd when compiling with MSVC - Do not
Koen van de Sande k...@tibed.net added the comment:
Could msvc9compiler_stripruntimes.diff still be considered for
inclusion in Python 2.6.3 (high priority?)?
A lot of .pyd's of third-party extensions are getting dependencies on
MSVCR90 added to the .pyd, which makes them not work if the
Koen van de Sande k...@tibed.net added the comment:
It probably won't make 2.6.3 as the final is just out. But can we have
it for 2.6.4?
Here's a link to the relevant discussion on ImageSIG: http://
mail.python.org/pipermail/image-sig/2009-October/005918.html
Looking at my local extensions
Christoph Gohlke cgoh...@uci.edu added the comment:
There are two easy to fix issues with the
msvc9compiler_stripruntimes.diff patch: 1) the dependency for 64-bit
VC90.CRT is not removed and 2) the VC90.CRT dependency is removed also
from executables, which will fail to run. A revised patch is
johan de taeye jdeta...@users.sourceforge.net added the comment:
Is the report posted in:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/3ec
6af1279a162ca#
also a symptom of the same problem?
Johan
--
nosy: +jdetaeye
___
Python
Koen van de Sande k...@tibed.net added the comment:
@johan: no it is not a symptom of the same problem. The problem you are
having is that the executable which is embedding Python does not have a
manifest. If you add a manifest with a dependency on the VC90 runtimes
to the main executable,
johan de taeye jdeta...@users.sourceforge.net added the comment:
@koen: You're aboslutely right. The issue is solved indeed by adding a
dependency in the manifest.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4120
Zach Hirsch zhir...@umich.edu added the comment:
Without msvc9compiler_stripruntimes.diff, or a patch like it, it doesn't
seem possible to use pywin32 (or other binary extensions) with
Python-2.6+ installed just for me (i.e., without the VC90 runtime
installed globally).
Using the python-2.6.1
Christian Heimes [EMAIL PROTECTED] added the comment:
Should this patch be applied to 3.0 before the next RC lands? Barry
hasn't released RC2 yet.
--
nosy: +christian.heimes
type: - compile error
versions: +Python 2.7, Python 3.0
___
Python tracker
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I have now committed Python-2.6-no.manifest.in.pyd.diff as r67120,
r67121, and r67122. Thanks for the patch.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4120
Martin v. Löwis [EMAIL PROTECTED] added the comment:
In r67125, r67126, r67127, r67128, r67129, I removed the mt.exe
invocation from tcl and tk, and removed the DLLs CRT manifest from the
installer.
___
Python tracker [EMAIL PROTECTED]
Andre Heider [EMAIL PROTECTED] added the comment:
I tried to use _CRT_NOFORCE_MANIFEST but i couldn't get it working.
There're some infos about this approach at
http://blog.m-ri.de/index.php/2008/05/06/hotfix-fuer-usemsprivateassembliesh-und-vc-2008/
, but even with the mentioned
Koen van de Sande [EMAIL PROTECTED] added the comment:
OK, so the define is not going to work. For Python extensions built
through distutils, the msvc9compiler_stripruntimes.diff patch will
work: it will remove just the dependency on the VC90runtimes. It will
leave other assembly dependencies
Martin v. Löwis [EMAIL PROTECTED] added the comment:
What would be the best way to integrate a search/replace
operation like this in the Python build process? Is the manifest
generated as a seperate file here first as well, or is it directly
embedded?
What's wrong with Andre Heider's
Koen van de Sande [EMAIL PROTECTED] added the comment:
Ah, I wasn't thinking it through. It is fine for all .pyd of course,
because they don't have any extra dependencies. I was thinking of DLLs
with extra dependencies (of which there is one, TK85.dll). There,
leaving out the manifest will
Mark Hammond [EMAIL PROTECTED] added the comment:
I don't see a problem with this and can see how it would help with
private assemblies.
--
nosy: +mhammond
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4120
Andre Heider [EMAIL PROTECTED] added the comment:
Skipping the mt.exe call seems fine to me, but there's another solution
which might be better:
The automatic manifest binding comes from a #pragma
comment(linker,/manifestdependency: directive in crtdefs.h. That can
be disabled by setting
Andre Heider [EMAIL PROTECTED] added the comment:
.. erm, the nmake line in Tools\buildbot\external.bat and
Tools/buildbot/external-amd64.bat ;)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4120
___
Koen van de Sande [EMAIL PROTECTED] added the comment:
_CRT_NOFORCE_MANIFEST sounds nice, but I'm having some trouble getting
it to work for Python extensions. I'm still having manifests
generated...? Can you show me how to use it? It is an undocumented
option.
Koen van de Sande [EMAIL PROTECTED] added the comment:
Instead of reverting the patch for Issue 2563, I propose to strip the
VC90 runtimes from the manifest (this will preserve other dependencies
needed). I checked this by editing tk85.dll and replacing the
dependency there with white-space -
Andre Heider [EMAIL PROTECTED] added the comment:
For some reason, the linker *does* generate manifest files for all the
.pyds when I try it out. Should that worry me? When I delete them, it
still can import them just fine.
Hm, works for me. I am using MS SDK v6.1 and PCbuild/build.bat.
This
Koen van de Sande [EMAIL PROTECTED] added the comment:
The TCL85.dll introduces a subtlety (actually it is TK85.dll). The
MSVCRT90 is not the only dependency that can be in the manifest. The
Windows.CommonControls.6.0 is used by TK85.dll. So, also for all Python
extensions which have
Changes by Martin v. Löwis [EMAIL PROTECTED]:
--
assignee: - loewis
priority: - high
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4120
___
___
Martin v. Löwis [EMAIL PROTECTED] added the comment:
For some reason, the linker *does* generate manifest files for all the
.pyds when I try it out. Should that worry me? When I delete them, it
still can import them just fine.
FWIW, with the patch alone, the manifest in .DLLs will still be
Andre Heider [EMAIL PROTECTED] added the comment:
To my surprise there indeed is a vista SP1 box in our test farm. We
tested my patch on the following windows machines (each without an
installed CRT redist):
- xp SP2 and SP3
- xp64 SP2
- server 2003 R2 SP1
- vista with and without SP1
- windows
New submission from Andre Heider [EMAIL PROTECTED]:
The MSVC build process currently embeds the .manifest file, which is
generated by the MS linker, in the following files:
- python.exe
- pythonXY.dll
- *.pyd
The latter is problematic on machines without the MS CRT redistributable
installed
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I'm skeptical about this patch. It seems like it could produce an
incompatibility with existing installations or deployment procedures. In
any case, the VS 2008 project files are not officially supported.
If VS 2005 is any similar with VS
Andre Heider [EMAIL PROTECTED] added the comment:
Yes, i know that v2.5 doesn't officially support MSVC9. But the same
problem applies to MSVC8 and its CRT. But in contrast to MSVC9, the CRT8
redist is installed on almost every machine, because alot of software
installs it. But thats basically
Andre Heider [EMAIL PROTECTED] added the comment:
Ok, point taken, so lets aim at v2.6. Should i open a new issue then?
Attached you'll find a new diff against v2.6. This time pyd_d.vsprops
gets patched too and the linker doesn't even generate a .manifest file.
So no, the *.pyd files do not get
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I'm just repurposing the issue (despite what I usually claim as a policy)
--
resolution: rejected -
status: closed - open
versions: +Python 2.6 -Python 2.5
___
Python tracker [EMAIL PROTECTED]
Changes by Martin v. Löwis [EMAIL PROTECTED]:
Removed file:
http://bugs.python.org/file11783/Python-2.5.2-no.manifest.in.pyd.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4120
___
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Yes, i know that v2.5 doesn't officially support MSVC9. But the same
problem applies to MSVC8 and its CRT.
The point is that even the MSVC8 project files are not supported.
They have been included, but they are not actually used for
Changes by Martin v. Löwis [EMAIL PROTECTED]:
--
resolution: - rejected
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4120
___
55 matches
Mail list logo
