Re: Building ORBit2 on Windows

[Tor Lillqvist <tml iki fi>]

> Well, I got it working. I switched from gcc 4.4.0 to gcc 3.4.5

OK, thanks, good to know. It might well be that the widespread use of
exported/imported data (variables) in ORBit2 and ORBit2-generated code
(which caused the warnings about auto-import you mentioned earlier) is
even more problematic than usual with gcc 4.4.0 then. It causes
complex problems. It has been several years since I had to look into
it so I don't remember the details any longer. You might find
something in messages by me in old threads on this list from 2005 or
2006 perhaps... Or in my entries in the ChangeLogs.

What I do remember is that there is a fundamental restriction in what
kinds of link-time expression can be handled by the COFF object
format, or run-time relocations that can be handled by the PE
executable format (those used on Windows), compared to the ELF format
used on Linux. The --enable-runtime-pseudo-reloc linker option used in
ORBit2 when built with MinGW is related to this, look up its
documentation.

The data structures used in ORBit2, and generated by its IDL compiler,
are such that in theory it needs expressions involving relocatable
addresses that the COFF object format is not expressive enough to
represent. (That sounds impressive, but don't be fooled, I don't
really know what I mean;)

If the compiler doesn't know that a variable is imported from a DLL
then the compiler doesn't notice, and it's just the linker that then
it has to do some more or less dirty tricks. On the other hand, if one
does tell the compiler that some variables are imported from a DLL,
the compiler says that the addresses of these variables are involved
in too complex expressions to be stored in the object file. Or
something like that. As I said, my memory is hazy. (On the other hand,
some people, if I recall correctly, do build ORBit2, and presumably
code generated by its IDL compiler, with Microsoft's tools, which
hardly do the same kind of tricks. Odd...)

It would require quite fundamental changes to the data structures
generated by the IDL compiler to get around these problems in a clean
way, and ORBit2 isn't used any longer by any software I would be
interested in.

And in any case, such changes would of course mean incompatibility if
used on Linux, and would require either forking a separate ORBit2
codebase for Windows, or a horrible ifdef mess.

--tml