Robin Dunn ro...@alldunn.com added the comment:
No, MSVC does not behave that way any longer. Now it simply creates a file
named None, so I expect that the newer versions simply do not support writing
the old-style debug info written to the DLL or EXE. If a setup script creates
more than one
New submission from Robin Dunn ro...@alldunn.com:
In Python 2.7b1, building on OSX 10.6 with this configure command:
export CC=gcc-4.0
export CXX=g++-4.0
export MACOSX_DEPLOYMENT_TARGET=10.4
../configure \
--with-universal-archs=32-bit \
--enable-universalsdk=/Developer/SDKs
Changes by Robin Dunn ro...@alldunn.com:
--
nosy: +robind
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7812
___
___
Python-bugs-list mailing list
Robin Dunn ro...@alldunn.com added the comment:
Update: I finally worked out what needed to be done for wxPython and
while simply changing Python's manifest would have been immensely easier
what I have does seem to work well so I thought I should give some info
here for posterity.
I went back
Robin Dunn ro...@alldunn.com added the comment:
Thanks for the code. I've verified your findings and I've also
converted nested to an extension module and built it with distutils and
was still able to make it correctly load the themed common controls when
imported from Python, however I had
Robin Dunn ro...@alldunn.com added the comment:
If I understand correctly then setting an activation context won't help
because by the time that an extension module is loaded the choice of
which version of the common controls DLL will be loaded has already been
made, and it may in fact already
Robin Dunn ro...@alldunn.com added the comment:
Ok, the following files will be attached:
python.exe.manifest: This is a copy of the manifest resource that I put
into the 2.6.1 python.exe file by hand for testing. The original
manifest was the same but without the 2nd dependency.../dependency
Changes by Robin Dunn ro...@alldunn.com:
Added file: http://bugs.python.org/file12996/sample.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5019
Changes by Robin Dunn ro...@alldunn.com:
Added file: http://bugs.python.org/file12997/Snap001.png
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5019
Changes by Robin Dunn ro...@alldunn.com:
Added file: http://bugs.python.org/file12998/Snap002.png
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5019
Robin Dunn ro...@alldunn.com added the comment:
Sorry, no luck. I've tried before to ensure that all the DLLs and
extension modules have the manifest file (in resource 2) and it makes no
difference. I rebuilt wxWidgets and wxPython today with
ISOLATION_AWARE_ENABLED defined to check
New submission from Robin Dunn [EMAIL PROTECTED]:
It looks like part of r59290 resulted in /pdb:None always being part of
the ldflags_shared_debug list. This means that there will be no debug
info stored for extensions built in debug mode, which kinda negates the
purpose of doing a debug build
New submission from Robin Dunn [EMAIL PROTECTED]:
OSX Leopard (10.5.4)
Python-2.6b2 tarball
./configure --enable-universalsdk --enable-framework
make
sudo make install
Ends with this error:
cd Mac make installmacsubtree DESTDIR=
Creating directory
/Library/Frameworks/Python.framework
New submission from Robin Dunn [EMAIL PROTECTED]:
OSX Leopard (10.5.4)
Python-3.0b2 tarball
./configure --enable-universalsdk --enable-framework
make
sudo make install
Ends with this error:
cd PythonLauncher make install DESTDIR=
test -d /Applications/Python 3.0 || mkdir -p /Applications
New submission from Robin Dunn [EMAIL PROTECTED]:
OS X Leopard (10.5.4)
Python-3.0b2 tarball
./configure --enable-universalsdk --enable-framework
make
sudo make install
/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app
is not created by the install step, but it is needed
15 matches
Mail list logo
