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