> 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 _______________________________________________ orbit-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/orbit-list
