Re: a problem porting an application from linux to windows, oh the agony -- please help?

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.
* *nix linkers generally export lib symbols by default, windows linkers
don't (AFAICR)
* Eliminate whoever wrote this from the gene-pool

.

Relevant Pages