+Tor Lillqvist <tml@iki.fi>
+Hans Breuer <hans@breuer.org>
+
+The general parts, and the section about gcc and autoconfiscated build
+are by Tor Lillqvist. The sections about MSVC build is by Hans Breuer.
+
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 operating system emulation layer
-except that provided by the Microsoft runtime C library. Additionally,
-a pthreads emulation library is used.
+For prebuilt binaries (DLLs and EXEs) and developer packages (headers,
+import libraries) of GLib, GTK+, GIMP etc for Windows, surf to
+http://www.gimp.org/win32/downloads.html . They are for "native"
+Windows meaning they use the Win32 API and Microsoft C runtime library
+only, no POSIX (Unix) emulation layer (like Cygwin).
-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 gcc-2.95 or gcc-2.95.2 as
-distributed by Mumit Khan, either as a mingw version (preferred), or
-running under cygwin. 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 called "mingw".
+To build GLib on Win32, you can use either gcc or the Microsoft
+compiler and tools. Both the compiler from MSVC 5.0 and from MSVC 6.0
+have been used successfully.
-To test the GLib functions, go to the tests subdirectory and enter
-`nmake -f makefile.msc check` or `make -f makefile.mingw check`.
+But note that to just *use* GLib on Windows, there is no need to build
+it yourself. Prepackaged runtime and developer packages are available
+from the website above. On Unix, it is quite normal that system admins
+build and install libraries like GLib themselves without bothering to
+look for prebuilt packages, especially if prebuilt packages tend to
+use installation paths that don't conform to local customs.
-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.
+On Windows setting up a correct build environment can be quite a task,
+especially if you are used to just type "./configure; make" on Unix,
+and expect things to work as smoothly on Windows.
-With a little work, it might be possible to use the ./configure
-mechanism also with a "mingw32" configuration.
+The following preprocessor macros are to be used for conditional
+compilation related to Win32 in GLib-using code:
-The following preprocessor macro are used for conditional compilation
-related to Win32:
+- G_OS_WIN32 is defined when compiling for native Win32, without
+ any POSIX emulation, other than to the extent provided by the
+ bundled Microsoft C library (msvcrt.dll).
-- G_OS_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.
+- G_WITH_CYGWIN is defined if compiling for the Cygwin
+ environment. Note that G_OS_WIN32 is *not* defined in that case, as
+ Cygwin is supposed to behave like Unix. G_OS_UNIX *is* defined when
+ compiling for Cygwin.
-- _WIN32 is defined by the compiler
+- G_PLATFORM_WIN32 is defined when either G_OS_WIN32 or G_WITH_CYGWIN
+ is defined.
-The Win32 port uses the combination with both of those on. As
-G_OS_WIN32 is defined in glibconfig.h, it is available to all source
-files that use GLib (or GTk+, which uses GLib).
+These macros are defined in glibconfig.h, and are thus (indirectly)
+available in all source files that include <glib.h> or GTK+ headers.
Additionally, there are the compiler-specific macros:
+- __GNUC__ is defined when using gcc
- _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 G_OS_WIN32.
-
-G_OS_WIN32 implies using the Microsoft C runtime MSVCRT.DLL.
-
-Building software that use GLib or GTk+
+- __DMC__ is defined when using the Digital Mars C/C++ compiler
+
+G_OS_WIN32 implies using the Microsoft C runtime MSVCRT.DLL. GLib is
+not known to work with the older CRTDLL.DLL runtime, or the static
+Microsoft C runtime libraries LIBC.LIB and LIBCMT.LIB. It apparently
+does work with the debugging version of MSVCRT.DLL,
+MSVCRTD.DLL. Presumably, if compiled with MSVC.NET, it also works with
+MSVCR70.DLL. Please note that it's dubious if you would be allowed by
+the license to distrubute a GLib linked to MSVCR70.DLL, as it is not
+part of the operating system, but of the MSVC product. MSVCRT.DLL is
+part of Windows.
+
+Building software that use GLib or GTK+
=======================================
-Unfortunately, even building software that just *use* GLib or GTk+
-also require to have the right compiler set up the right way, so if
-you intend to use gcc, follow the relevant instructions below in that
-case, too.
-
-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.mingw. 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.mingw file. You should copy the
-corresponding makefile.msc.in or makefile.mingw.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.
+Even building software that just *uses* GLib or GTK+ also require to
+have the right compiler set up the right way, so if you intend to use
+gcc, follow the relevant instructions below in that case, too.
+
+Tor uses gcc with the -mms-bitfields flag (used to be called
+-fnative-struct in gcc 2.x), which means that in order to use the
+prebuilt DLLs (especially of GTK+), if you compile your code with gcc,
+you *must* also use that flag. This flag means that the struct layout
+rules are identical to those used by MSVC. This is essential if the
+same DLLs are to be usable both from gcc- and MSVC-compiled code. This
+definitely is something one wants.
+
+Building GLib
+=============
+
+Again, first decide whether you really want to do this.
+
+Before building GLib you must also have the libiconv library and GNU
+gettext. Get prebuilt binaries of libiconv (1.9.1 or newer), and
+gettext-runtime (0.13.1 or newer) from www.gimp.org/win32/downloads.html.
+
+Autoconfiscated build (with gcc)
+================================
+
+Tor uses gcc 3.3.1. Somewhat earlier or later versions presumably also
+work.
+
+You can either use gcc running on Cygwin, or the "pure" mingw
+gcc. Using the latter might work better, or at least did at some
+point. You should be running Cygwin, or maybe cross-compiling from
+real Unix, for the configure script to work, obviously. It is also
+possible to use MSYS.
+
+If you want to use mingw's gcc, install gcc, Win32 headers and
+binutils from www.mingw.org. Set up your PATH so that the mingw gcc is
+the one that gets used, and not Cygwin's gcc. Even if you run the
+mingw gcc, you still want to have Cygwin to run make in.
+
+Tor invokes configure using:
+
+CC='gcc -mcpu=pentium3' CPPFLAGS='-I/target/include'
+ CFLAGS=-O3 LDFLAGS='-L/target/lib' ./configure --with-libiconv
+ --disable-gtk-doc --prefix=/target --host=i386-pc-mingw32
+
+(on a single line). The /target/include mentioned contains the header
+files for libintl and libiconv, and the (import) libraries are in
+/target/lib. This happens to be in the same tree where he configures
+GLib to be installed, but doesn't have to be.
+
+Please note that the ./configure mechanism should not blindly be used
+to build a GLib to be distributed to other developers because it
+produces a compiler-dependent glibconfig.h (and config.h, but that
+shouldn't matter, as it isn't seen by GLib-using applications). For
+instance, the typedef for gint64 is long long with gcc, but __int64
+with MSVC.
+
+Except for this and a few other minor issues, there really shouldn't
+be any reason to distribute separate GLib headers and DLLs for gcc and
+MSVC users, as the compilers generate code that uses the same C
+runtime library. The DLL generated by either compiler is binary
+compatible with the other one. Thus one either has to manually edit
+glibconfig.h afterwards, or use the supplied glibconfig.h.win32 which
+has been produced by running configure twice, once using gcc and once
+using MSVC, and merging the resulting files with diff -D.
+
+For GLib, the DLL is called
+libglib-2.0-0.dll, and the import libraries libglib-2.0.dll.a and
+glib-2.0.lib. Note that the "2.0" is part of the "basename" of the
+library, it is not something that libtool has tucked on. The -0 suffix
+is the value of "LT_CURRENT - LT_AGE". The 0 is *not* simply the micro
+version number of GLib, although, for GLib 2.2.0, it happens to be the
+same. The LT_CURRENT - LT_AGE value will on purpose be kept as zero as
+long as binary compatibility is maintained. For the gory details, see
+configure.in and libtool documentation.
+
+If you want to run the Cygwin-hosted gcc, and still want to produce
+code that does not use Cygwin, but the msvcrt runtime, in theory it
+should work to use the -no-cygwin flag, but Tor hasn't tested that
+lately.
+
+If you would want to use the Cygwin tools to generate a GLib that
+*does* use the Cygwin runtime, the normal Unix configuration method
+should work as if on Unix. Note that successfully producing shared
+libraries (DLLs) for Cygwin most probably requires you to have a very
+new libtool. (And a new libtool probably requires rather new autoconf
+and automake.) Tor hasn't tested this in a while, either.
+
+Cross-compiling
+===============
+
+It is possible to build GLib using a cross compiler. See
+docs/reference/glib/html/glib-cross-compiling.html (part of the
+GLib reference manual) for more information.
Building with MSVC
==================
-If using the Microsoft toolchain, build with `nmake -f
-makefile.msc`. Install with `nmake -f makefile.msc install`.
-
-Building with gcc
-=================
-
-I use the latest and greatest gcc, gcc-2.95.2. 2.95 will also work.
-Earlier version might, but you are on your own.
-
-You can either use gcc running on cygwin, or the "pure" mingw
-gcc. Using the latter is much easier. Just fetch the latest version of
-gcc for mingw and the msvcrt runtime, currently from
-ftp://ftp.nanotech.wisc.edu/pub/khan/gnu-win32/mingw32/snapshots/gcc-2.95.2-1/
-. Download the three zip archives: the gcc-<version>-msvcrt,
-mingw-msvcrt-<timestamp> and binutils-<timestamp>-msvcrt, and unpack
-them in a suitable directory. Set up your PATH so that the gcc from
-the bin directory that got created above is the one that gets
-used. You can skip steps 1--5 below. Even if you run the mingw gcc,
-you still want to have cygwin to run make in.
-
-If you want to run a cygwin-based gcc, it gets much more
-complicated. We still want gcc to produce code that does not use
-cygwin, but the msvcrt runtime. Read the below instruction carefully
-and understand them. If you don't understand or can't follow the
-instructions, you probably shouldn't want to build GLib (or GTk+ or
-GIMP) yourself anyway.
-
-0) Get and install Cygwin B20.1.
-
- Move the include files and libraries included in Cygwin out of the
- way not to mix things up... (For example, rename
- /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/lib to
- lib-no-thanks and rename
- /cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/include to
- include-no-thanks.
-
-1) Get gcc 2.95.2 built for Cygwin B20.1 from
- ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/gcc-2.95.2-cygb20.tar.gz
-
- Install it somewhere, let's say G:\gcc-2.95.2 (//g/gcc-2.95.2 when
- in Cygwin). Add //g/gcc-2.95.2/H-i586-cygwin32/bin to your
- PATH. I assume you use bash below.
-
- Replace the specs file in
- //g/gcc-2.95.2/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95.2/specs
- with the following. (The changes are: Define __MSVCRT__, replace
- the "1" versions of the crt files with the "2" ones, replace crtdll
- with msvcrt. Also, extra whitespace squished. )
-
-================ cut here ================
-*asm:
-
-
-*asm_final:
-
-
-*cpp:
--remap %(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{!mno-cygwin:-D__CYGWIN32__ -D__CYGWIN__} %{mno-cygwin:-iwithprefixbefore ../../../../%(mingw_include_path)/include/mingw32 -D__MSVCRT__ -D__MINGW32__=0.2}
-
-*cc1:
-%(cc1_spec)
-
-*cc1plus:
-
-
-*endfile:
-
-
-*link:
-%{mwindows:--subsystem windows} %{mconsole:--subsystem console} %{mdll:--dll -e _DllMainCRTStartup@12}
-
-*lib:
-%{pg:-lgmon} %{!mno-cygwin:-lcygwin} %{mno-cygwin:-lmingw32 -lmoldname -lmsvcrt} %{mwindows:-lgdi32 -lcomdlg32} -luser32 -lkernel32 -ladvapi32 -lshell32
-
-*libgcc:
--lgcc
-
-*startfile:
-%{mdll: %{mno-cygwin:dllcrt2%O%s}} %{!mdll: %{!mno-cygwin:crt0%O%s} %{mno-cygwin:crt2%O%s} %{pg: %{!mno-cygwin:gcrt0%O%s} %{mno-cygwin:gcrt2%O%s}}}
-
-*switches_need_spaces:
-
-
-*signed_char:
-%{funsigned-char:-D__CHAR_UNSIGNED__}
-
-*predefines:
--Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -Asystem(winnt) -Acpu(i386) -Amachine(i386)
-
-*cross_compile:
-0
-
-*version:
-2.95.2
-
-*multilib:
-. !mno-cygwin;mingw32 mno-cygwin;;
-
-*multilib_defaults:
-
-
-*multilib_extra:
-
-
-*multilib_matches:
-mno-cygwin mno-cygwin;
-
-*linker:
-collect2
-
-*cpp_486:
-%{!ansi:-Di486} -D__i486 -D__i486__
-
-*cpp_586:
-%{!ansi:-Di586 -Dpentium} -D__i586 -D__i586__ -D__pentium -D__pentium__
-
-*cpp_k6:
-%{!ansi:-Di586 -Dk6} -D__i586 -D__i586__ -D__k6 -D__k6__
-
-*cpp_686:
-%{!ansi:-Di686 -Dpentiumpro} -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__
-
-*cpp_cpu_default:
-%(cpp_586)
-
-*cpp_cpu:
--Acpu(i386) -Amachine(i386) %{!ansi:-Di386} -D__i386 -D__i386__ %{mcpu=i486:%(cpp_486)} %{m486:%(cpp_486)} %{mpentium:%(cpp_586)} %{mcpu=pentium:%(cpp_586)} %{mpentiumpro:%(cpp_686)} %{mcpu=pentiumpro:%(cpp_686)} %{mcpu=k6:%(cpp_k6)} %{!mcpu*:%{!m486:%{!mpentium*:%(cpp_cpu_default)}}}
-
-*cc1_cpu:
-%{!mcpu*: %{m386:-mcpu=i386 -march=i386} %{m486:-mcpu=i486 -march=i486} %{mpentium:-mcpu=pentium} %{mpentiumpro:-mcpu=pentiumpro}}
-
-*mingw_include_path:
-i586-cygwin32
-
-*link_command:
-%{!fsyntax-only: %{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %D %o %{!nostdlib:%{!nodefaultlibs:%G %L %G}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*}
- }}}}}}
-
-================ cut here ================
-
-2) Get the Mingw32 runtime sources from
- ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/gcc-2.95.2/runtime-source-19991107.zip
-
- Unpack it somewhere, say //g/src/mingw-runtime-19991107 .
-
- Apply the following patches:
-
- This makes the mingwm10.dll depend on the stuff that is needed
- to build it.:
-
-================ cut here ================
-diff -ru2 ./mingw/Makefile.in ../../src/mingw-runtime-19991107/mingw/Makefile.in
---- ./mingw/Makefile.in Sun Nov 07 12:19:22 1999
-+++ ../../src/mingw-runtime-19991107/mingw/Makefile.in Mon Nov 08 14:55:38 1999
-@@ -138,5 +138,5 @@
- --base-file mingwthrd.base --output-exp mingwthrd.exp
-
--$(THREAD_DLL_NAME) mingwthrd.def: $(DLL_OFILES) Makefile
-+$(THREAD_DLL_NAME) mingwthrd.def: $(DLL_OFILES) Makefile libmingw32.a libmoldname.a lib$(RUNTIME).a dllcrt$(CRT_ID).o
- $(DLLTOOL) --as $(AS) --output-def mingwthrd.def $(DLL_OFILES)
- $(CC) -Wl,--base-file=mingwthrd.base $(DLL_CC_STUFF)
-================ cut here ================
-
- This enables building the profiling gcrt2.o. I don't know how useful
- it is, though, there doesn't seem to be any gprof command in cygwin.
-
-================ cut here ================
-diff -ru2 ./mingw/profile/Makefile.in ../../src/mingw-runtime-19991107/mingw/profile/Makefile.in
---- ./mingw/profile/Makefile.in Sun Nov 07 12:18:56 1999
-+++ ../../src/mingw-runtime-19991107/mingw/profile/Makefile.in Mon Nov 08 12:12:12 1999
-@@ -76,8 +76,8 @@
-
- gcrt1.o: gcrt0.c
-- $(CC) -U__MSVCRT__ -c -o $@ $(CPPFLAGS) $(CFLAGS) $?
-+ $(CC) -U__MSVCRT__ -c -o $@ $(CPPFLAGS) $(ALL_CFLAGS) $?
-
- gcrt2.o: gcrt0.c
-- $(CC) -D__MSVCRT__ -c -o $@ $(CPPFLAGS) $(CFLAGS) $?
-+ $(CC) -D__MSVCRT__ -c -o $@ $(CPPFLAGS) $(ALL_CFLAGS) $?
-
- Makefile: Makefile.in config.status configure
-================ cut here ================
-
- This fixes a typo in wingdi.h:
+If you are building from a CVS snapshot, you will not have any
+makefile.msc files. You should copy the corresponding makefile.msc.in
+file to that name, and replace any @...@ strings with the correct
+value.
+
+This is done automatically when an official GLib source distribution
+package is built, so if you get GLib from a source distribution
+package, there should be makefile.msc files ready to use (after some
+editing).
+
+The hand-written makefile.msc files, and the stuff in the "build"
+subdirectory, produce DLLs and import libraries that match what the
+so-called autoconfiscated build produces.
+
+All the MSVC makefiles are for the command line build with nmake. If
+you want to use the VC-UI you can simply create wrapper .dsp makefiles
+(read the VC docs how to do so).
+
+Some modules may require Perl to auto-generate files. The goal (at
+least Hans's) is to not require any more tools.
+
+Build with:
+
+nmake -f makefile.msc
+ or
+nmake -f makefile.msc DEBUG=1
+
+[
+ The former will create 'release' versions of the DLLs. If you
+ plan to distribute you DLLs please use this command. The latter
+ will create DLLs with debug information _and_ link them with
+ msvcrtd.dll instead of msvcrt.dll.
+ Beware: There are known problems with mixing DLLs in one
+ application, which are build against different runtimes.
+ Especially the index-to-file mapping used by 'unix-style' file
+ operation - _open() _pipe() etc. - breaks sometimes in strange
+ ways (for example the Gimp plug-in communication).
+]
+
+Required libraries (not build from cvs)
+------------------
+ libintl (gnu-intl), libiconv
+ libtiff, libpng, zlib, libjpeg
+
+are available pre-built from the website mentioned above.
+
+Versioning
+----------
+Instead of the Unix and auto* way of tracking versions and resolving
+dependencies (configure; make; make install) involving autoconf,
+automake, libtool and friends the MSVC build uses a different
+approach.
+
+The core of it's versioning is the file build/win32/module.defs.
+It contains entries of the form MODULE_VER, e.g.:
+
+ GLIB_VER = 2.0
+ LIBICONV_VER = 1.3
+
+and the placement of these modules defined as MODULE, e.g.:
+
+ GLIB = $(TOP)/glib
+ LIBICONV = $(TOP)/libiconv-$(LIBICONV_VER)
+
+whereas TOP is defined as the relative path from the respective
+module directory to your top build directory. Every makefile.msc
+needs to define TOP before including the common make file part
+make.msc, which than includes module.defs, like:
+
+TOP = ../..
+!INCLUDE $(TOP)/glib/build/win32/make.msc
+
+(Taken from gtk+/gdk/makefile.msc)
+
+With this provision it is possible to create almost placement
+independent makefiles without requiring to 'install' the libraries and
+headers into a common place (as it is done on Unix, and as Tor does
+when producing his zipfiles with prebuilt GLib, GTK+ etc).
+
+Special Files
+-------------
+ config.h.win32.in : @XXX_MAJOR_VERSION@ needs to be replaced by
+the current version/build number. The resulting file is to be saved
+as 'config.h.win32'. This should be automatically done if a package
+gets build on the Unix platform.
+
+ makefile.msc.in : @XXX_MAJOR_VERSION@ to be replaced. Save as
+makefile.msc.
+
+ <module>.def : every function which should be used from the outside of
+a dll needs to be marked for 'export'. It is common that one needs to change
+these files after some api changes occured. If there are variables to be
+exported another mechanism is needed, like :
+
+ #ifdef G_OS_WIN32
+ # ifdef GDK_COMPILATION
+ # define GDKVAR __declspec(dllexport)
+ # else
+ # define GDKVAR extern __declspec(dllimport)
+ # endif
+ #else
+ # define GDKVAR extern
+ #endif
+
+
+
+Directory Structure
+-------------------
+all modules should be build in a common directory tree otherwise you
+need to adapt the file 'module.defs'. They are listed here in increasing
+dependencies order.
+
+<common rootdir without spaces>
+ |
+ +- glib
+ | |
+ | +- build : [this module lives in the cvs root dir]
+ | | +- win32
+ | | .\module.defs : defines (relative) locations of the headers
+ | | and libs and version numbers to be include
+ | | in dll names
+ | | .\make.msc : include by almost every 'makefile.msc'
+ | |
+ | | .\README.WIN32 : more information how to build
+ | | .\glibconfig.h.win32.in : similar to config.h.win32.in
+ | | .\makefile.msc : master makefile, sub dir makefiles should work
+ | |
+ | +- glib
+ | +- gmodule
+ | +- gthread : does _not_ depend on pthread anymore
+ | +- gobject
+ |
+ +- pango
+ | +- pango : 'native' build does not require extra libs and
+ | | includes the minimal required text renderer
+ | | (there is also a currently slightly broken FreeType2
+ | | based implementation for win32)
+ | +- modules (not yet build)
+ |
+ +- atk
+ | +- atk
+ | .\makefile.msc : build here
+ |
+ +- gtk+
+ | | .\config.h.win32 : for all the below
+ | |
+ | +- gdk-pixbuf
+ | | .\gdk_pixbuf.rc.in : version resource for the DLLs. Needs
+ | | to be converted (filled with version info)
+ | | as described above.
+ | |
+ | +- gdk
+ | | | .\makefile.msc : some auto-generation is needed to build in the
+ | | | in the subdirectory
+ | | +- win32
+ | |
+ | +- gtk
+
+ |
+ +- gimp
+ | .\makefile.msc : master makefile to build The Gimp. The makefiles
+ | from the sub dirs should work stand alone, but than
+ | the user needs to know the build order
+
+ |
+ +- dia : additionally depends on libart_lgpl (in cvs)
+ | and libxml2 ( see http://www.xmlsoft.org/ )
+ +- lib
+ +- app
+ +- objects
+ +- plug-ins
+ +- python
-================ cut here ================
-diff -ru2 ./w32api/include/wingdi.h ../../src/mingw-runtime-19991107/w32api/include/wingdi.h
---- ./w32api/include/wingdi.h Thu Nov 04 03:42:40 1999
-+++ ../../src/mingw-runtime-19991107/w32api/include/wingdi.h Mon Nov 08 12:48:02 1999
-@@ -304,5 +304,5 @@
- #define FW_BOLD 700
- #define FW_EXTRABOLD 800
--#define FW_ULTRABOLD FW_EXTRABOOLD
-+#define FW_ULTRABOLD FW_EXTRABOLD
- #define FW_HEAVY 900
- #define FW_BLACK FW_HEAVY
-
-================ cut here ================
-
- fpos_t should be long long with MSVCRT.DLL:
-
-================ cut here ================
---- stdio.h~ Thu Aug 19 02:47:42 1999
-+++ stdio.h Mon Jan 17 21:58:20 2000
-@@ -296,6 +296,11 @@
- * it is fairly evident that the fpos_t type is a long (in CRTDLL.DLL).
- * Perhaps an unsigned long? TODO?
-+ * In MSVCRT.DLL it's a long long, however.
- */
-+#ifdef __MSVCRT__
-+typedef long long fpos_t;
-+#else
- typedef long fpos_t;
-+#endif
-
- int fgetpos (FILE* fileGetPosition, fpos_t* pfpos);
-================ cut here ================
-
-
- (I haven't checked yet if other small errors I have noticed in
- previous w32api header versions have been corrected.)
-
-3) Now you should build the mingw32 and w32api runtime and import libraries.
-
- Go to //g/src/mingw-runtime-19991107/w32api. Enter:
-
- CC='gcc -mno-cygwin' ./configure i586-pc-mingw32msvc
- make
-
- That should complete in a while. It should produce a lot of .a
- libraries (both import libraries, and a couple of archive
- libraries), and some .o files. I don't trust make install to do
- what I want (especially as I didn't give any --prefix argument to
- the configure...), so I install the stuff manually:
-
- cd lib
- mkdir //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32
- cp *.a //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32
- cp crt2.o crtdll2.o //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32
- cd ../include
- mkdir //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32
- cp *.h //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32
-
- Now go to ../../mingw, and run the same configure command, and do a
- make:
-
- CC='gcc -mno-cygwin' ./configure i586-pc-mingw32msvc
- make
-
- Then install the mingw32 libraries and headers:
- cp *.a //g/gcc-2.95.2/H-i586-cygwin32/lib/mingw32
- mkdir //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32/sys
- cp include/sys/*.h //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32/sys
- cp include/*.h //g/gcc-2.95.2/H-i586-cygwin32/i586-cygwin32/include/mingw32
-
-
-4) Get an updated set of binutils for cygwin B20.1 from
- ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95.2/binutils-2.9.4-cygb20.tar.gz
- Unpack that in your /cygnus/cygwin-b20 directory. The relevant
- difference is: dlltool now parses GCC generated export directives
- correctly for DATA items.
-
-5) Whew. That hopefully should be it.
-
-Next, go back to the GLib directory and build using `make -f
-makefile.mingw`. 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>
projects / platform / upstream / glib.git / blobdiff