Re: Building ORBit2 on Windows

[Tor Lillqvist <tml iki fi>]

> I'm in the midst of implementing DII, so a distributed binary isn't good enough.

I don't understand what you mean with that? *what* distributed binary
isn't good enough for *what* purpose?

> 4. Symlink all the DLLs into a .libs directory and add it to the path:

That is a quite strange thing to do. Firstly, there aren't really any
symlinks in the Unix sense on Windows, so what the "ln -s" command in
MSYS does is just create a copy. (In my personal opinion, it is
misleading to even provide such a "fallback" ln command. Reasonable
scripts and other mechanisms know that there are no symlinks on
Windows and do not even attempt to run ln -s.)

Secondly, the directory name ".libs" is used in the build tree when
using .libtool. But that is just an internal implementation detail of
how libtool works. Even if DLLs directly after having been built are
in .libs subdirectories that doesn't mean you are supposed to have the
DLLs in a directory with that name when running them. (OK, so it
doesn't do any harm as such, ".libs" is just a name, but it is
misleading.)

Thirdly, not all DLLs produced in a build of ORBit2 are needed by
ORBit2-using programs at run-time. Not all DLLs are "shared libraries"
that programs (or other shared libraries) would link to. A DLL can
also be a "module". (The difference is just in usage, technically
their format is the same. Just like .so files on ELF-based systems
like Linux.) The Everything_module.dll is such a "module", it is just
used by "make check". It is definitely not supposed to be in PATH.
(OK, so again this doesn't do any harm, it is just misleading.)

What you should have done is simply run "make install". That would
have copied the files that make up the public API and run-time
environment (headers, import libraries, run-time shared libraries,
executable programs etc) into the installation destination tree (what
you specified as --prefix when running the configure script).

> 5. Test it
>> make check

"make check" is supposed to be runnable right after building, without
having to "make install" first. (But like so many things when adapting
Unix-based tools to Windows, it is not necessarily always like that,
due to bugs in various places. Often it indeed is best to make sure
the DLLs that one have built are in PATH, even if that is supposed to
be automatically taken care of by the "make check" mechanisms.)

> At this point, I can't start the server in test/everything.  When I
> try to run it by hand, I get "The application failed to initialize
> properly (0xc0000005)".

I *think* that could mean there is something seriously wrong happening
in the DllMain() code. Try add debugging printouts in it (in
src/orb/orb-core/corba-orb.c). On the other hand, if you are using the
master or ORBit2, the DllMain() is extremely simple (as DllMain
functions are supposed to be) and can't really be causing this
trouble. Maybe what it means is just that some DLL is missing from
PATH.

I guess I should warn you that the libIDL binaries on ftp.gnome.org
haven't been tested in quite a while, there might well have crept in
some incompatibility with the latest glib for instance, altrhough I
can't think of what that would be.

--tml