Re: a problem porting an application from linux to windows, oh the agony -- please help?
- From: mwojcik@xxxxxxxxxxx (Michael Wojcik)
- Date: 24 Jun 2005 19:10:28 GMT
In article <d9fhcb$seu$1@xxxxxxxxxxxxxx>, Igor Kaplounenko <igor@xxxxxxxxxxxxxxx> writes:
> 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 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...
This really looks like a question for a Windows programming group
and not comp.programming, which is for general, platform- and
language-independent programming questions. I'd set followups but
I don't read any of them regularly.
> 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.
I believe that's the Microsoft C runtime's array of FILE objects for
stdio. stdin is &_iob[0], stdout is &_iob[1], and so on. (The
additional leading underscore is added by the compiler to certain
external names, as part of the dizzying array of Windows linkage
conventions.)
Or it could be the same thing from someone else's C runtime - the
name "_iob" is used by several C implementations. You're using the
MinGW C compiler, but you don't say whose C runtime you're linking
against.
> Could the source of my problem lie here?
Could be. Certainly you can run into nasty memory corruption with
Windows programs that link two or more C runtimes, which is a
situation you can easily encounter. Microsoft C compiler products
and SDKs come with an assortment of C runtimes. MSVC6, for example,
has single- and multi-threaded static-linked, dynamic-linked, and
"debug" dynamic-linked runtimes (ie at least six). If one part of
the application is linked with one runtime and another part is
linked with another, and the application causes anything that's not
shared to be passed from one runtime to another, you're likely to
get an illegal dereference.
For example, if you take a FILE* opened by one runtime and pass it
to a C I/O function in another runtime, you're dead. Similarly
with a pointer returned by malloc in one runtime, passed to free in
another. And so forth.
The MS utility "depends" will show all the dependencies for an EXE
or DLL. If you don't already have it installed, it can be freely
downloaded from somewhere in the MS webmaze.
> ... 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.
You can tell the Microsoft toolchains (and I expect the Gnu ones as
well) which linking conventions to use for a given symbol, which will
solve this problem. Different linkage conventions decorate names in
different ways. This is all in the documentation for the Microsoft
tools, but I can't easily point you to it, since I don't know what
sort of docs you have available.
--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx
The history of Namco begins in 1955 when the Company's predecessor
began operating rocking-horse rides on the rooftop of a department
store in Yokohama. Since then, we have pioneered diverse forms of
amusement and entertainment that help people live their dreams. As
we approach the 21st century, an "Era of Spirituality", Namco will
help to spread dynamic entertainment throughout the world.
-- video game producer Namco's English-language Japanese web page
.
- Prev by Date: Re: looking for programming competitions
- Next by Date: Re: Which programming language is better to start
- Previous by thread: Re: a problem porting an application from linux to windows, oh the agony-- please help?
- Next by thread: mesa tesselator
- Index(es):
Relevant Pages
|
