glib/README.win32
Tor Lillqvist 4d7172def0 Win32: With the latest gcc (2.95, pre-release), we can have binary
compatibility with MSVC by using the switch -fnative-struct. No
 	longer build DLLs with .gcc in the name when using gcc.

	* README.win32: Renew gcc build instructions.

	* build-dll: Comments change, handle also .a files.

	* makefile.cygwin.in
	* tests/makefile.cygwin.in: Remove .gcc from DLL name.
1999-07-21 19:18:03 +00:00

146 lines
5.6 KiB
Plaintext

General
=======
For more information about the port or GLib, GTk+ and the GIMP to
native Windows, and pre-built binary packages, see
http://www.iki.fi/tml/gimp/win32/ . "Native" means that we use the
Win32 API only, and not any POSIX emulation layer except that provided
by the Microsoft runtime C library. Additionally, a pthreads emulation
library is used.
To build GLib on Win32, you can use either the Microsoft compiler and
tools, or gcc. Both the compiler from MSVC 5.0 and from MSVC 6.0 have
been used successfully. With gcc I mean the gcc-2.95 pre-release as
distributed by Mumit Khan, running under cygwin-b20.1. To successfully
use gcc, follow the instructions below. We want to use gcc
-mno-cygwin, i.e. produce executables (.exe and .dll files) that do
*not* require the cygwin runtime library. This is sometimes called
"mingw32".
To test the GLib functions, go to the tests subdirectory and enter
`nmake -f makefile.msc check` or `make -f makefile.cygwin check`.
If you would want to use the cygwin tools to generate executables that
*do* use the cygwin runtime, the normal Unix configuration method
should work as if on Unix. But it won't produce DLLs. At least I
haven't succeeded in that.
With a little work, it might be possible to use the ./configure
mechanism also with a "mingw32" configuration.
The following preprocessor macros are defined in glibconfig.h and used
for conditional compilation related to Win32:
- WIN32 is defined when compiling for the Win32 platform, regardless
if using the X11 or Win32 windowing API (in the case of GLib, this
dimension isn't significant), regardless whether using a more or
less complete POSIX emulation runtime layer (like Cygwin) or not.
- NATIVE_WIN32 is defined when compiling for Win32, *and* without
any POSIX emulation, other that to the extent provided by the
bundled Microsoft C library (msvcrt.dll) and the pthreads-win32
library. For instance, pathnames are in the native Windows syntax.
The Win32 port uses the combination with both of those on. As these
are in glibconfig.h, they are available to all source files that use
GLib (or GTk+, which uses GLib).
Additionally, there are the compiler-specific macros:
- _MSC_VER is defined when using the Microsoft compiler
- __GNUC__ is defined when using GCC
Some of the usage of these macros used to be a bit mixed up, and had
to be straightened out when adding the gcc support. In particular, I
used to check for _MSC_VER in some places where I really wanted to
check for the Microsoft C library, and those checks has now been
changed to NATIVE_WIN32. NATIVE_WIN32 ought to be renamed to
USE_MSVCRT.
Pthreads library
================
Before building you must get the pthreads library for Win32 from
http://sourceware.cygnus.com/pthreads-win32/. The pthreads-win32
snapshot from 1999-05-30 is the one that should be used. Edit the
location of the pthreads library and include files in makefile.msc or
makefile.cygwin. The pthreads distribution includes the precompiled dll
and import libraries both for MSVC and gcc.
The pthreads for Win32 package that the thread support uses supposedly
isn't quite ready yet, and thus threads stuff should not be relied
upon for anything serious.
Where are the makefiles?
========================
If you are building from a CVS snapshot, you will not have any
makefile.msc or makefile.cygwin file. You should copy the
corresponding makefile.msc.in or makefile.cygwin.in file to that name,
and edit the line that sets GLIB_VER to the correct version number.
This is done automatically when an official distribution package is
built.
Building with MSVC
==================
If using the Microsoft toolchain, build with `nmake -f
makefile.msc`. Install with `nmake -f makefile.msc install`.
Building with gcc
=================
The gcc support was added quite recently, but seems to work. Debugging
with gdb works. I use the latest and greatest gcc and mingw32.
Somewhat earlier versions will also work, but you are on your own.
Fetch the gcc-2.95 developer snapshot from
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/snapshots/gcc-2.95-19990715/.
Install it somewhere, for instance \gcc-2.95.
Fetch the mingw runtime snapshot from 1999-07-15 from
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/runtime/. You
must fix two bugs in it:
1) Fix the prototype and call to __getmainargs() in init.c to include
one more parameter, an int *, which should be passed the address of a
zero int. Code snippets below:
...
#ifdef __MSVCRT__
extern void __getmainargs(int *, char***, char***, int, int *);
#else
...
#ifdef __MSVCRT__
int newmode = 0;
(void) __getmainargs(&_argc, &_argv, &dummy_environ, _CRT_glob, &newmode);
#else
...
2) Fix the type of the function __p___argv() in stdlib.h to be char***,
not char**.
Build the mingw32 runtime and install the libraries in the
gcc-2.95\H-i586-cygwin32\lib directory, and the headers in the
gcc-2.95\H-i586-cygwin32\i586-cygwin32\include\mingw32 directory.
Remember to build and install also the w32api import libraries and
headers.
I prefer to use the msvcrt runtime and not the default
crtdll. Especially, as the pthread library also uses msvcrt, using
crtdll would probably not be a good idea at all. Using msvcrt can be
achieved by applying a few changes to the specs file.
The specs file is in gcc-2.95\H-i586-cygwin32\lib\gcc-lib\i586-cygwin32\2.95
The necessary changes are: replace -lcrtdll with -lmsvcrt, replace
crt1 with crt2, change -lmoldname to -lmoldname-msvc, and define
__MSVCRT__.
Next, go back to the GLib directory and build using `make -f
makefile.cygwin`. Building the dlls uses the script build-dll which
is somewhat of a hack. But I couldn't get things working in a cleaner
way.
--Tor Lillqvist <tml@iki.fi>