Python 2.4 under WinXP, free VC71 toolkit and VC6 libraries

  • Thread starter =?iso-8859-15?q?Berthold_H=F6llmann?=
  • Start date
?

=?iso-8859-15?q?Berthold_H=F6llmann?=

I have wrapped some inhouse libraries for Python. The development team
uses VC6 and DF6.1 for development of these libraries under WinXP. I
would like to wrap the libraries for Python and use the official Win
Python from python.org. Now I get a segmentation fault in (access
violation in NTDLL.DLL). The code used to work on Python 2.3, so I
am afraid I have a plroblem in mixing the code generated by different
VC versions. Is this the probable cause of my problem, or should the
combination work in general (some libraries seem to work).

Kind regards
Berthold
 
F

F. Petitjean

Le Tue, 27 Sep 2005 17:48:47 +0200, Berthold Höllmann a écrit :
I have wrapped some inhouse libraries for Python. How ? Directly coding C code ?
The development team
uses VC6 and DF6.1 for development of these libraries under WinXP. DF6.1 is Digital FORTRAN 6.1 ?
I
would like to wrap the libraries for Python and use the official Win
Python from python.org. Now I get a segmentation fault in (access
violation in NTDLL.DLL). The code used to work on Python 2.3, so I
am afraid I have a plroblem in mixing the code generated by different
VC versions. Is this the probable cause of my problem, or should the
combination work in general (some libraries seem to work).

Kind regards
Berthold
A possible solution would be to write any VC6 and DF6.1 code to generate
some DLLs (black boxes) and to use these DLLs from Python by using
ctypes, to build your applications. All the CPU intensive code should be
in DLLs and the high level stuff (GUI, presentation, application logic,
....) could be in python. (GUI with wnd or venster for example).

Regards.
 
G

Guest

F. Petitjean said:
Le Tue, 27 Sep 2005 17:48:47 +0200, Berthold Höllmann a écrit :
How ? Directly coding C code ?

Depends :) f2py, directly coding C, SWIG.
DF6.1 is Digital FORTRAN 6.1 ?
Yes

A possible solution would be to write any VC6 and DF6.1 code to generate
some DLLs (black boxes) and to use these DLLs from Python by using
ctypes, to build your applications. All the CPU intensive code should be
in DLLs and the high level stuff (GUI, presentation, application logic,
...) could be in python. (GUI with wnd or venster for example).

As I understand it, ctypes is not really a solution. The code is about
data handling and FE analysis. It has not GUI component. I'm not sure
how well ctypes works with Numeric arrays, but I'm sure ctypes does
not work on Linux and Solaris, but my code has to.

Regards.
 
P

Peter Hansen

Berthold said:
As I understand it, ctypes is not really a solution. The code is about
data handling and FE analysis. It has not GUI component. I'm not sure
how well ctypes works with Numeric arrays, but I'm sure ctypes does
not work on Linux and Solaris, but my code has to.

Neither of those comments makes sense, so you probably _don't_
understand what ctypes is. Not only does it definitely work on Linux,
but it has nothing to do per se with GUI components, and should work
fine for "data handling" of just about any kind that is done by a DLL.

I'm not sure what you were thinking of, but it probably wasn't ctypes.

-Peter
 
?

=?iso-8859-15?q?Berthold_H=F6llmann?=

Peter Hansen said:
Neither of those comments makes sense, so you probably _don't_
understand what ctypes is. Not only does it definitely work on Linux,
but it has nothing to do per se with GUI components, and should work
fine for "data handling" of just about any kind that is done by a DLL.

I'm not sure what you were thinking of, but it probably wasn't ctypes.

OK, then. ctypes works under Linux and Solaris. But before I even
think about converting my code to ctypes (and convert lots of Linux
libraries from static to dynamic libraries), would the conversion
really address my problem? As I understand it, if there is an
incompatibility between VC6 and VC7 compiled libraries the issue comes
turns up with ctypes as well as with my current extension modules?

Kind regards
Berthold
 
F

Fredrik Lundh

Berthold said:
OK, then. ctypes works under Linux and Solaris. But before I even
think about converting my code to ctypes (and convert lots of Linux
libraries from static to dynamic libraries), would the conversion
really address my problem? As I understand it, if there is an
incompatibility between VC6 and VC7 compiled libraries the issue comes
turns up with ctypes as well as with my current extension modules?

this thread is getting more and more bizarre. are you seeing VC6/VC7 com-
patibility issues on Linux and Solaris?

(to answer your original question, you can often link VC7 code against a
VC6 library, but not always; some C features are implemented as macros
that depend on internal struct layouts, and inlined code sometimes depend
on the exact semantics of support functions in the C runtime libraries, etc.
You can get the same kind of problems if you're mixing /M different options
under the same compiler. And no, ctypes won't recompile your libraries
for you, so those issues are still there. Since VC7 is the current offering
from Microsoft, you should ask for an up-to-date version from your library
provider. If they cannot provide a version for the current Microsoft com-
piler, you may have to stay with Python 2.3 for the time being...)

</F>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,241
Members
46,831
Latest member
RusselWill

Latest Threads

Top