RE: Odd behaviour when building on Win32 using MinGW

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

Hi,

It's not my intention to be difficult -- I just thought that it would
benefit the gtk+ community if there was an agreement on how to build
certain libraries so that they would be binary compatible with each
other. I thought this should be possible without burdening those who
maintain and develop those libraries.

A simple set of instructions on how to build those libraries would be
enough. 

Notes on using MinGW+Cygwin:
To make things work -- at least on my machine -- I've had to do the
following:
Added the following to the top of cygwin.bat:
CALL f:\vs6\vc98\bin\VCVARS32.BAT
SET PATH=f:\MinGW\bin;%PATH%

Edited etc/profile:
PATH="/f/MinGW/bin:/usr/local/bin:/usr/bin:/bin:$PATH"
export PATH

PKG_CONFIG_LIBDIR=/f/MinGW/lib/pkgconfig
export PKG_CONFIG_LIBDIR

Added environment variables CPATH and CPLUS_INCLUDE_PATH as per gcc
documentation

This info should probably be added to a trouble shooting section of some
readme file.

Best regards
Espen Harlinn 

> -----Original Message-----
> From: gtk-devel-list-admin gnome org 
> [mailto:gtk-devel-list-admin gnome org] On Behalf Of Tor Lillqvist
> Sent: 29. august 2003 22:54
> To: Espen Harlinn
> Cc: gtk-devel-list gnome org
> Subject: RE: Odd behaviour when building on Win32 using MinGW
> 
> 
> 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
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org 
> http://mail.gnome.org/mailman/listinfo/gtk-> devel-list
>