printf "fails" in extension

[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

Alex Martelli <aleax at aleax.it> wrote in message news:<Ma9kb.306506$R32.10072711 at news2.tin.it>...
> Robert Ferrell wrote:
> 
> > 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