RE: Odd behaviour when building on Win32 using MinGW

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

Hi,
 
> That sounds like a bad idea to me... so if somebody wants to 
> upgrade to a newer build of Pango, for instance, without 
> changing anything else, he wouldn't be able to do that?
OK, let me put it this way - for now - each company using gtk+ on win32
should have their own distribution - and if they upgrade to a newer
version - they would only risk breaking their own software - or a set of
standardization rules could be developed for gtk+ on win32 - most
importantly:
	1: size of enum must be equal to size of an integer, 32-bit (M$
VC++ 6.0 doesn't support anything else)
	2: 8-byte structure alignment (Supported by all compilers)
	3: __cdecl calling convention (Supported by all compilers)
(__stdcall could be used but this would require serious changes to all
the header files)
	4: *.def files with ordinal numbers for all exported functions
and data (just do a make and use pexport to 
         extract the *.def file, include that *.def file in the
distribution)
	5: call
SetErrorMode(SEM_FAILCRITICALERRORS|SEM_NOGPFAULTERRORBOX|SEM_NOOPENFILE
ERRORBOX) in glib DllMain 
	   this ensures that the software doesn't display unwanted
dialog boxes, and the OS return error codes or 
	   throws structured exceptions. This is very important for
server software. (doing 'make check' on glib (using MinGW+MSYS)
illustrates this problem)

1,2 and 3 should be enforced by the gtk+ header files. 2 and 3 is what
you normally get when you compile gtk+ on win32 unless you do something
specific on the command line to achieve something else.
 
> So, basically you are saying, "there are several incompatible 
> zlib builds for Windows floating around, so I'll have to make 
> yet another one"? Why don't standardize on one of the 
> existing zlib DLLs?

AFAIK no standard compilation for win32 does what you really want -
deflateInit,inflateInit,deflateInit2,inflateInit2 are commented out, as
they should be - but they should still be exported from the library -
since some people doesn't bother to include zlib.h in their source code.
Also most standard compilations of zlib for windows doesn't use the
assembler code. Calling convention differs between static (__cdecl) and
dynamic (__stdcall) linking - and you have to define ZLIB_DLL if you
want to use the dll. If you do zconf.h pulls in windows.h, just get at
two definitions WINAPI (__stdcall) and WINAPIV (__cdecl). This makes
porting code that depends on zlib to win32 rather painful - sometimes
open source projects have an entirely different notion of a particular
definition than the windows headers - and it slows down compilation.

libjpeg defines boolean sometimes as an 8-bit entity, sometimes as a
32-bit entity depending on the compiler.

libtiff contains some *very* useful extension in the contrib directory,
particularly the mfs subdirectory. 

libfreetype2: read the file in docs\INSTALL.ANY and you will see that
it's possible to have some very incompatible version of this library.

There are probably similar issues with each of the other libraries the
gtk+ depends on.

> Why do you include the compiler version number, up to three 
> levels, in the DLL name? When you upgrade to gcc 3.3.2 (say, 
> for instance some serious bug is discovered in gcc 3.3.1 that 
> affects your code), will you produce new builds of everything?
> 
> Also, including the overall release version number of some 
> library in its DLL name(s) is something that generally isn't 
> considered a good idea. That's why libtool uses the interface 
> age and related concepts. The DLL name should stay the same 
> as long as binary compatibility is maintained.

My point exactly, but sometimes things gets changed between minor
versions that WILL break binary compatibility. This is more likely to
happen with the win32 ports of gcc since gcc still has some seriously
missing features - things that most probably will be put in as soon as
somebody has added the feature - most notably c++ COM compatibility and
structured exception handling. (I'm not sure about the structured
exception handling part - if there is a way to deal with structured
exceptions using gcc I would love to know about it :-) ).

> Is your suggestion that everybody who distributes any 
> software has to build all the dependencies themselves, naming 
> them uniquely? Sounds hellish.
Yes (in the future hopefully no), and yes it is. I'm not trying to argue
that my solution is the best - it isn't - the point I'm trying to make
is that gtk+ for win32 needs some kind way to deal with the problems
I've outlined. Gtk+ includes it's own version of the trio library - on
win32 it should probably also include it's own version of:
libz, libpng, libtiff, libjpeg, libintl, libiconv,
libfreetype2,fontconfig, expat and libxml2 - or a set of instructions on
how to build them correctly for use with gtk+ on win32.
I know libxml2 isn't used by gtk+ itself, but many other gtk+/glib based
libraries uses this library and I've yet to execute 'make check' for
libxml2 without drowning in errors using MinGW+MSYS.

Building M4 using MinGW+MSYS and doing a 'make check' makes me suspect
that there are some serious issues with regard to sh.exe and how it
deals with '\r\n' and '\n'.
Making sure all handles in M4 are binary reduces the number failures to
4, and those are all related to the standard io handles.  

Best regards
Espen Harlinn