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

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.*

.

Relevant Pages

  • Re: DFPORT
    ... I work on a Windows XP platform. ... We normally use F77 Fortran and for this one problematic program we ... Since we also have the Intel Fortran compiler, we also had a lot of ... Windows Fortran comper (with appropriate libraries). ...
    (comp.lang.fortran)
  • Re: - E02 - Support for MinGW Open Source Compiler
    ... No Python abilities are required, either, for that matter. ... And the fact that building *any* Windows native program without commercial ... compiler suites installed *somewhere*. ... Also, vcproj2make has a dependency on PyXML, which isn't necessarily obvious ...
    (comp.lang.python)
  • Re: pygame and python 2.5
    ... I committed to Python because it's a great language. ... modules on the Windows platform without having a copy of Visual Studio ... developing a math library based on GMPY to use ... obsolete compiler that's not even available. ...
    (comp.lang.python)
  • Re: about presicion
    ... > Windows between any two releases of Python and will presumably ... What I meant was the OP can't compare Decimal and gmpy unless he has ... > file) compiled for the version of Python you're using. ... Would the command line c compiler from the MS SDK suffice or do you ...
    (comp.lang.python)
  • Re: calling a function that returns a c_char from python
    ... compiler used, the output in python is right or wrong. ... The problem could lie either on the python side or the Fortran side. ... character arguments was defined in f77. ...
    (comp.lang.fortran)