Subj : Re: a problem porting an application from linux to windows, oh the agony -- please help?
To   : comp.programming
From : Rob Thorpe
Date : Wed Jun 29 2005 06:07 am

Igor Kaplounenko wrote:
> Rob Thorpe wrote:
> > Igor Kaplounenko wrote:
> >
> >>I'm working on porting a monstrosity written in Python, C, an Fortran
> >>(interfacing Fortran with Python using f2py) from linux to Windows XP.
> >>On linux I'm compiling the code using Intel Fortran Compiler v8.0 and
> >>gcc 3.2.3 with the corresponding linker.  On Windows it's IFC 8.0.047
> >>for windows and MinGW's gcc 3.4.2 with Microsoft's incremental linker
> >>7.10.3077 that comes with their free C++ Toolkit.  I have to use IFC
> >>because the code is f90.  Otherwise i'd use g77.  Everything works just
> >>swell on linux, but on Windows the fortran dlls invoked from python
> >>crash mysteriously without specifying the nature of the problem, and my
> >>first guess would be that it is a memory error.  My belief that this
> >>might be the case is compounded by the fact that for some reason the
> >>program -- a heart modeling application using finite element method --
> >>works for complicated models but will crash on a very simple one, and,
> >>furthermore, the simple model would work if I enable the fortran flag
> >>that generates additional diagnostics output (DOP.  it's a simple
> >>fortran boolean that's been part of our program since pre-historic
> >>times) (i.e. goes through some trivial print statements inside IF(DOP)
> >>statements scattered through the program).
> >>The only clue the linker gives me as it puts the object files together
> >>is that it gives me the following warning:
> >>
> >>fem_meshmodule.o : warning LNK4217: locally defined symbol __iob
> >>imported in function _f2py_rout_fem_mesh_p_calcline
> >>fortranobject.o : warning LNK4049: locally defined symbol __iob imported
> >>
> >>This would seem ominous if I actually knew what __iob is.  I got the
> >>impression that it has something to do with i/o, but google only managed
> >>to answer all the questions i didn't ask, and none of results gave me
> >>the definition of __iob.  Could the source of my problem lie here?
> >>Another issue I've considered was mixing mingw and windows compilers.
> >>Initially I wanted to build the c objects using microsoft's cl, to make
> >>sure that everything is compatible with everything else.   However, when
> >>f2py generates wrapper code for fortran to be interfaced with python, it
> >>  generates code that's not only barely-human-readable, but also isn't
> >>parseable by cl due to too many nested if-else statements which result
> >>in compiler stack overflow.  Hence I'm stuck using gnu unless there's a
> >>better alternative.  I considered using Borland, but then I have to deal
> >>with COFF vs OMF formats and more linker warnings/errors...  I was
> >>already having trouble with gnu vs microsoft objects expecting imported
> >>symbols with different numbers of underscores prepended... *sigh*, and
> >>that makes it impossible to mix gnu and windows libraries, and yet I
> >>have to since my compilers come from these separate worlds.
> >>So that's pretty much it.  Would more information be useful in resolving
> >>this? If so, what?  I could attach the list of libraries I use during
> >>linking, since some of them are MinGW/MSYS yet others Microsoft, and
> >>that may cause problems as far as I know, but it's a bit long.
> >
> >
> > This kind of stuff is really hard unfortunately.
> >
> > __iob is probably an array of FILE structs built to simulate the
> > Fortran I/O blocks.
> >
> > Possibly useful suggestions:-
> >
> > * Check the calling conventions used are consistent everywhere.
> I'm not entirely sure on this one, but gcc uses cdecl, correct? I
> believe that to be the default calling convention for ifort as well.

cdecl is the name microsoft use for the calling convention that their C
compiler uses by default.  It use the normal C method of right to left
argument passing.  It's decribed in:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core___cdecl.asp

I'm not sure if GCC uses *precisely* the same convention, or if GCC
running under MinGW does.

> > * *nix linkers generally export lib symbols by default, windows linkers
> > don't (AFAICR)
> That could only possibly result in actual linking errors, though, right?
>   Not warnings.

Yes, unless something somewhere (like a linker switch in a makefile)
tells it to export by default and it's not doing it quite right or
quite everywhere.

As another suggested, try a windows group like something in
comp.os.ms-windows.programmer.*

.