RE: Odd behaviour when building on Win32 using MinGW

["Espen Harlinn" <espen harlinn seamos no>]

Hi,
 
> 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.

I've tested the following:
Depending on the version of libtool, libtool will generate a *.def file
in the .libs directory for a given library based on the dll found using
the dlname='../bin/some.dll' entry in the *.la file. It seems to ignore
the library_names='some.dll.a' entry. The distributions often uses an
old version of libtool - i.e. pre 1.5

So far I've been able to build libgnomecanvas-2.3.6 - but this is hardly
a smooth process, lots of manual intervention ,and while things do build
they are buggy.
 
> 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?

So far I haven't found the "Right Way" to do this, I've written a small
C++ utility that takes the original def file and adds the __imp_ and _
aliases for the exported functions - but this invoked manually.
 
> > 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.

Their defaults are much the same, else bcc would be horribly broken.
Even the C++ virtual function tables are laid out in the same manner.

 > > 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.)

Write a DllMain function and get the name of the module using the handle
passed as an argument to GetModuleFileName and store the result in a
global variable and use it to calculate the other paths.


Take a look at the makefiles, and you will see the atk for instance
wants to know the path to the locale dir as
-DATKLOCALEDIR=\""$(atklocaledir)"\" and this is hardcoded in the
makefile.

So far I've written the following functions:
/*
 * Get information on various paths
 */
extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_install_directory();
/* this is an alias for __ewin_get_prefix_directory() */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_prefix_directory();
/* same as $(prefix) from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_bin_directory(); /*
same as $(prefix)/bin from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_lib_directory(); /*
same as $(libdir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_include_directory();
/* same as $(includedir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_data_directory(); /*
same as $(datadir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_locale_directory();
/* same as $(datadir)/locale from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_info_directory(); /*
same as $(infodir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_libexec_directory();
/* same as $(libexecdir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char *
__ewin_get_local_state_directory(); /* same as $(localstatedir) from
makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_man_directory(); /*
same as $(mandir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_sbin_directory(); /*
same as $(sbindir) from makefile */

extern LIBEWIN_DLL_EXPORTED const char *
__ewin_get_shared_state_directory(); /* same as $(sharedstatedir) from
makefile */

extern LIBEWIN_DLL_EXPORTED const char * __ewin_get_sysconf_directory();
/* same as $(sysconfdir) from makefile */

The __ewin_ prefix should probably be replaced with something like
g_syspath or something. 

As long as a function is named
g_win32_get_package_installation_directory it will never be used by most
of the gtk developers since they mostly develop for unix, and will most
likely either scorn win32 compability or think that this function should
only be used in the win32 port of gtk and apps/libs built on top of
that. 

If glib/atk/pango/gtk and so on used this or a similar (possibly
extended) set of functions on all platforms instead of the hardcoded
stuff from the makefiles, quite a lot of code would be considerably
easier to maintain.

Best regards
Espen Harlinn