--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Out of curiosity: can you please try invoking this enum_print to stdout
with your VS2005-built boost module? I see it uses fprintf, so I would
expect it to crash.
After beating on this for half an hour I am coming to the conclusion that there
is no
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
P.P.S. You do know that this configuration (extension compiled
with VS2005, Python compiled wit VS.NET2003) is not supported,
right?
Thanks to Adal's help I got all our C++ extensions (about 50) to work with VC8.
I am using Python 2.4.2 compiled
Ralf W. Grosse-Kunstleve wrote:
However, we don't have any home-grown
C++ GUI code. Could it be that problems due to mixing objects from different
compiler versions are restricted to certain areas, like GUI libraries?
Well, yes: the areas are
- memory management
- stdio
- locales
for the C
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Well, yes: the areas are
- memory management
- stdio
- locales
for the C library; for the C++, I'm not so sure, but I think one of the
areas is
- static members of class templates, in particular in STL containers
Thanks for the insight! For
Ralf W. Grosse-Kunstleve wrote:
- there is only one FILE* that is seen by Visual C++. It appears in the
signature of a function assigned to the tp_print slot. As far as I can tell
this is the only soft spot. I'll lobby for having the print function removed
since it is optional and both tp_str
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
which means that DLLs used by the extension will be searched
IN THE EXTENSION FOLDER and not on PATH.
Try putting msvcp80.dll right next to your extension DLL.
It is a little strange that it is not loaded directly from the
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
I am using a Visual Studio 2005 Professional installation. I also ran
vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't
help. However, standalone executables work OK without any gymnastics.
--- Adal Chiriliuc [EMAIL PROTECTED] wrote:
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
which means that DLLs used by the extension will be searched
IN THE EXTENSION FOLDER and not on PATH.
Try putting msvcp80.dll right next to your extension DLL.
I tried that
Adal Chiriliuc wrote:
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
which means that DLLs used by the extension will be searched
IN THE EXTENSION FOLDER and not on PATH.
Can you please refer to the part of the documentation that documents
that PATH is not searched? In
Ralf W. Grosse-Kunstleve wrote:
I wasn't sure about that. In the transition from VC 6 to VC 7.x we didn't
have compatibility problems. I was hoping this trend continues ...
That was by pure luck only. Other people did have problems.
If that's not the case we will need two Python 2.5
On Tuesday, December 27, 2005 Ralf W. Grosse-Kunstleve wrote:
Sorry, the manifests are new to me. How can I check if the manifest is
correctly embedded?
FWIW: I already tried copying the manifest into the directory with the
extensions.
To check if you have a manifest you need to use a tool
--- Adal Chiriliuc [EMAIL PROTECTED] wrote:
Then you need to run mt.exe to embedd the manifest:
mt.exe /outputresource:cctbx_math_ext.pyd;#2 /manifest
cctbx_math_ext.pyd.manifest
That is the magic trick! After applying the mt command to all our extensions
most of our unit tests work even with
We have a bunch of C++ extensions (Boost.Python) that work fine under
Windows when compiled with Visual C++ 7.1. With a few minor tweaks
all extensions also compile with Visual C++ 8.0, but trying to import
any of the extensions fails with this message (shown in a pop-up box):
This application
Ralf W. Grosse-Kunstleve wrote:
I am using a Visual Studio 2005 Professional installation. I also ran
vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't
help. However, standalone executables work OK without any gymnastics.
Does anyone know what the problem could be with the
14 matches
Mail list logo