printf "fails" in extension

[Robert Ferrell]

I'm trying to "extend" Python by writing a bit of C code. I followed
the example in the Python documentation, and almost everything works
fine. I can build a DLL, fire up an interactive Python session and
import my new module. Methods work almost as expected.

The only problem I'm having is that I can't print to the screen from
the C code. Printing to a file works fine, but neither printf nor
fprintf(stdout,...) puts anything onto the screen.

I'm working in Windows2K, using Python2.3. Is there some trick to get
this to work? I'm wondering if this is a compiler issue (I'm building
the DLL using an Absoft compiler). I googled around looking for
relevant information, but I didn't find any. Perhaps I didn't have
the right key words?

Any ideas,
thanks,
-robert

 

[Alex Martelli]

I'm trying to "extend" Python by writing a bit of C code. I followed
the example in the Python documentation, and almost everything works
fine. I can build a DLL, fire up an interactive Python session and
import my new module. Methods work almost as expected.

The only problem I'm having is that I can't print to the screen from
the C code. Printing to a file works fine, but neither printf nor
fprintf(stdout,...) puts anything onto the screen.

I'm working in Windows2K, using Python2.3. Is there some trick to get
this to work? I'm wondering if this is a compiler issue (I'm building
the DLL using an Absoft compiler). I googled around looking for
relevant information, but I didn't find any. Perhaps I didn't have
the right key words?

This may well be the case. Python doesn't necessarily have much
to do with it: it IS a question of EXE and DLL on Windows needing
to share the _same_ stdio infrastructure -- basically, the same
instance of the same runtime libraries. Tricky enough when you
build EXE and DLL with the same compiler, because even then you
need to ensure they're using a version of the C runtime that lives
_in yet another DLL_ -- and it must be the same, not e.g. one
optimized and the other built for debug instead -- any static
linking of the runtime on either or both sides and you're hosed.
Even trickier with different compilers, unless one is specifically
built to use the C runtime DLL's from the other -- mingw32 being
an example (it's built to use MSVCRT.DLL, Microsoft's DLL version
of the C runtime libraries).

This is a well-known issue among experts of C compilers on
Windows -- particularly ones who have ever had the totally
harrowing experience of having to mix code built by multiple
compilers, but not exclusively, because even using e.g MSVC++ 6
throughout is still tricky due to the possibility of different
C runtime library instances being used by different modules
(in the Windows sense: each EXE or DLL is a module). How to
manage to google for it may be a different issue, particularly
as the workaround (if any) will depend on your "Absoft
compiler". I can however suggest to skip Python in your
searches, because it's not in the picture: what you need to
find out is, how (if at all) is it possible to use your
compiler to write a DLL which, used from a MSVC++ - made EXE,
is able to do normal output to stdout or stderr.


Alex

 

[Just]

I'm trying to "extend" Python by writing a bit of C code. I followed
the example in the Python documentation, and almost everything works
fine. I can build a DLL, fire up an interactive Python session and
import my new module. Methods work almost as expected.

The only problem I'm having is that I can't print to the screen from
the C code. Printing to a file works fine, but neither printf nor
fprintf(stdout,...) puts anything onto the screen.

I'm working in Windows2K, using Python2.3. Is there some trick to get
this to work? I'm wondering if this is a compiler issue (I'm building
the DLL using an Absoft compiler). I googled around looking for
relevant information, but I didn't find any. Perhaps I didn't have
the right key words?

Apart from these potential issues (I know nothing about them), you
should really use PySys_WriteStdout() and PySys_WriteStderr(), because
these to the right thing when sys.stdout/sys.stderr are redirected to
something else.

Just

 

[Robert Ferrell]

Thanks for your response. I suspected this was a Windows DLL issue,
arising from my lack of experience with Windows, but I thought I
should confirm that I wasn't missing something obvious. My simplest
solution may be to switch to Visual Studio, although it's not clear
the customer will allow that.

Thanks for your input.
-robert

 

[Robert Ferrell]

In stuff I write I can use the appropriate Python routines. However,
part of the task is to extend Python with existing routines by adding
some wrapper code. That is something I know many others have done,
and is fairly straight forward. However, I dont' have the liberty of
converting all printf's in the existing code to Python-ese.

Thanks,
-robert

 

[Werner Schiendl]

Hi,

Thanks for your response. I suspected this was a Windows DLL issue,
arising from my lack of experience with Windows, but I thought I
should confirm that I wasn't missing something obvious. My simplest
solution may be to switch to Visual Studio, although it's not clear
the customer will allow that.

If price is the matter, you can download the "Platform SDK" for free
from Microsoft's homepage - and AFAIK it contains the command line
version of the compiler + all libraries just like Visual Studio does.

IMHO it could save you some trouble to use the same compiler for Python
itself and your extensions. Also be sure to build *both* as debug or
release (that is, both the *same*) since you will otherwise end up with
2 different versions of the C runtime libraries!

hth

Werner

 

[Werner Schiendl]

Hi,

In stuff I write I can use the appropriate Python routines. However,
part of the task is to extend Python with existing routines by adding
some wrapper code. That is something I know many others have done,
and is fairly straight forward. However, I dont' have the liberty of
converting all printf's in the existing code to Python-ese.

Then you *certainly* want to use the same C runtime library, everything
else will cause you a lot of headaches...

And as I said in my other post, be sure to have everything built with
the same build specification (debug or release) if you use the MS tools.

hth
Werner