RE: Odd behaviour when building on Win32 using MinGW

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

Hi,

> You still didn't tell how g_syspath_get_lib_directory(void), 
> a function presumably in GLib, could know what the lib 
> directory of some random other software is. Or would you 
> require that all GLib-using software is configured with the 
> same --prefix (on Windows, installed in the same location)?

Basicly - yes, or rather all glib using software should have it's own
private version of glib/atk/pango and so on. 
As Michael Torrie mentioned in an other reply to the list, a standard
distribution might resolve some of the problems that will inevitably
arise from installing various gtk+ dlls copiled by different people (OK
he didn't mention all that, but I assume that this is one of his reasons
for requesting a standard distribution). Your compilation of GTK might
not be 100% compatible with my compilation, so for distribution purposes
we must either have a standard distribution for GTK ( and GNOME when/if
we get that far :-) ), or a way to brand the dlls so they wont get mixed
up. As you probably know this is one of the reasons we all 'love'
windows - but my customers want windows, and that's something I can't
change.

Currently I have separate builds of
libz,libjpeg,libtiff,libpng,libiconv,libintl,libfreetype2,libglib,libgmo
dule,libgthread,libgobject,libatk and libpango for:
Borland C++ builder 6.0
M$ Visual C++ 6.0
MinGW (gcc 3.3.1)

And I'm using the following scheme to name the dlls

lib$(name)-$(branding)-$(compilersignature)-$(libraryversion)[-$(debugfl
ag)].dll

So building zlib 1.1.4 with C++ builder 6 results in a dll:
 libz-ewin-bcc6-1.1.4.dll (release version)
And
 libz-ewin-bcc6-1.1.4-d.dll (debug version)

Building zlib with MinGW results in
 libz-ewin-mingw-gcc3.3.1-1.1.4.dll (release version)
And
 libz-ewin-mingw-gcc3.3.1-1.1.4-d.dll (debug version)

I know this seems rather awkward - but at least if I've got something
working right for one application, changing the branding allows me to
change the compilation options to something needed by another
application without breaking the first application. Not all versions of
the zlib dll are equal - the standard build does not export some of the
functions needed by many libraries, and some builds use __stdcall and
some use __cdecl. From looking at the source for libtiff I would assume
that this library would also be built differently by different people.

I'm obviously using my own set of makefiles - but I still need to be
able to go through the ./configure, make, make check and make install
cycle - that is I need to know how things are supposed to work - before
writing my own versions of the makefiles. Making gtkmm work with C++
builder and Visual C++ would be awfully nice.

I'm also making two new implementations of ghtread - one based on Apache
apr-0.9.3 and another based on ACE
(http://www.cs.wustl.edu/~schmidt/ACE.html). I've completed the first
one - and you might find apr interesting since it provides a solution to
some of the problems you have mentioned about porting Orbit2 to win32.

Of cause I would be happy contribute this code - should anybody be
interested - just tell me where to send it.

Best regards
Espen Harlinn