RE: Odd behaviour when building on Win32 using MinGW

[Tor Lillqvist <tml iki fi>]

> I started out using the pre-built binaries and dev packages from
> your site, and they seems to work fairly OK except that building
> other packages on top of them is rather painful - mostly because of
> old libtool versions - no __imp_ prefixed exports in your packages.

You mean actual exports from the DLL, or names in the import library?
For instance, the libglib-2.0.dll.a import library *does* have both
symbols like __imp__g_utf8_strlen and _g_utf8_strlen. Also the MSVC
import library glib-2.0.lib seems to define the same symbols.

If it's just the import library that's lacking the correct kind of
magic for you, can't you generate an own one using some appropriate
tool, based on the exported entry points in the DLL?

> Since I'm also rather fond of Borland C++ builder, I would like to
> add a set of _ prefixed exports too. The resulting binaries should
> be usable with M$ vc, gcc(mingw) and Borland C++ builder.

Are you sure Borland's struct packing convention is identical to
MSVC's, for instance? If it isn't, using my prebuilt GTK DLL isn't
going to work anyway.

> IMHO: In an ideal world glib for windows should include a set of
> functions returning the paths to the various directories usually
> specified in the makefiles on unix.  Theese functions should return
> directories based on the location of the glib dll.

Er, why should GLib-using software care where GLib is installed? GLib
itself *does* look up its installation location at run-time on
Windows, and uses it to locate its message catalogs.

But anyway, there *is* such a function,
g_win32_get_package_installation_directory(). Its API design is
perhaps not the clearest imaginable, but it does work. GLib-using
software could use g_win32_get_package_installation_directory (NULL,
"libglib-2.0-0.dll") to get the GLib installation directory. (But why
it would need to know that I don't know.)  (And another question is
how can it know what the GLib DLL name is... The 2.0-0 part of the
name hasn't really much relation to the GLib version number.)

> > FAIL: module-test

> This seems to be a bug in the test script, not gmodule.
> This is from module-test:

Ah. The module-test (no extension) script is some crap libtool has
cooked up. I tend to throw them away, and mv .libs/*.exe .
instead... Libtool also generates some odd wrapper exes that usually
don't work either, but mv'ing the actual exes over them helps ;-) (And
then setting PATH yourself when running the tests.)

Using libtool on Win32 really is a pain. It's a bit silly that the
libtool scripts takes tens of seconds (on my 450 MHz P3) to figure out
how to start gcc, which then compiles a source file in a second or
so. And then again for the next file to be compiled the same all over
again. I have been tempted to write a quick ersatz libtool in C that
would take the same arguments and do the right thing.

--tml