RE: Odd behaviour when building on Win32 using MinGW

[Tor Lillqvist <tml iki fi>]

Espen Harlinn writes:
 > 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)

This presumably already is so, as the gcc-generated code is binary
compatible with MSVC?

 > 	3: __cdecl calling convention (Supported by all compilers)

This is the default, isn't it, so nothing special is needed.

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

Why? Why isn't export/import by name enough? Isn't export/import by
ordinal number some relic from 16-bit Windows and/or 286 class
machines, where one had to save on everything and use every trick to
get enough performance?

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

Can't such server software then call that function itself?

 > (doing 'make check' on glib (using MinGW+MSYS) illustrates this
 > problem)

Is it a problem? After all, GLib doesn't do signal (SIGSEGV, SIG_IGN)
or signal (SIGILL, SIG_IGN) (or whatever) or Unix either. Message
boxes are Windows's way to tell that an unhandled exception has
occured. If an application wants to avoid them, it can do whatever
magic is necessary itself, it's not GLib's business, IMHO.

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

As they are the default anyway, why would they have to be enforced by
the headers then?

 > AFAIK no standard compilation for win32 does what you really want -
 > [...] 

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

As you seem to have looked into these matters in much detail, why
don't you contact the official maintainers of these libraries (and
maybe those you know of who produce incompatible binary
distributions), and try to work out some canonical Windows build
procedure and ABI? Or at least cooperate with the "gnuwin32" guy at
sourceforge? (Whose ports of libtiff, zlib etc are what I use.)

 > Gtk+ includes it's own version of the trio library

(Actually it's GLib). Yes, but that's not something Windows specific,
it uses the included trio on all platforms where the OS-supplied C
library's printf isn't good enough.

 > - on win32 it should probably also include it's own version of:
 > libz, libpng, libtiff, libjpeg, libintl, libiconv, libfreetype2,
 > fontconfig, expat and libxml2

Nnnngh cough cough nooo nooo. If it comes to this, then I'll quit the
binary distribution business ;-(

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

Don't use MSYS then, use MinGW+Cygwin.

--tml