| Tor Lillqvist <tml@iki.fi> |
| Hans Breuer <hans@breuer.org> |
| |
| The general parts, and the stuff about gcc and autoconfiscated build |
| are by Tor Lillqvist. The stuff about MSVC build is by Hans Breuer. |
| |
| General |
| ======= |
| |
| 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/ . 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 gcc or the Microsoft |
| compiler and tools. Both the compiler from MSVC 5.0 and from MSVC 6.0 |
| have been used successfully. |
| |
| 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 webiste above. On Unix, it is quite normal that system admins |
| build and install libraries like GLib themselves. But on Windows |
| setting up a correct build environment can be quite a task, especially |
| if you are used to on Unix just type ./configure; make, and expect |
| things to work as smoothly on Windows. |
| |
| The following preprocessor macros can be used for conditional |
| compilation related to Win32 in GLib-using code: |
| |
| - 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_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. |
| |
| - G_PLATFORM_WIN32 is defined when either G_OS_WIN32 or G_WITH_CYGWIN |
| is defined. |
| |
| 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 |
| |
| 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. |
| |
| Building software that use GLib or GTK+ |
| ======================================= |
| |
| 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 -fnative-struct flag, which means that in order to |
| use the prebuilt DLLs (especially of GTK+), 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, either |
| from the same website mentioned above, or from it's homepage at |
| http://clisp.cons.org/~haible/packages-libiconv.html. Libiconv has |
| makefiles for building with MS Visual C only, but as it is one source |
| file only, building it "by hand" with gcc isn't hard. |
| |
| You must also have the "intl" library from GNU tettext 0.10.40 (or |
| later). Get a prebuilt version from the website mentioned above. |
| |
| Edit the correct paths to those libraries in build/win32/module.defs |
| as appropriate. |
| |
| Where are the makefiles? |
| ======================== |
| |
| If you are building from a CVS snapshot, you will not have any |
| makefile.mingw or makefile.msc files. You should copy the |
| corresponding makefile.mingw.in or 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.mingw and makefile.msc files ready |
| to use (after some editing). |
| |
| Building GLib with gcc |
| ====================== |
| |
| Tor uses gcc-2.95.3. Version 2.95.2 will most probably 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. |
| |
| Fetch the latest version of gcc for mingw and the msvcrt runtime, from |
| www.mingw.org. |
| |
| Set up your PATH so that the gcc from the bin directory that got |
| created above is the one that gets used. Even if you run the mingw |
| gcc, you still want to have Cygwin to run make in. |
| |
| Then run make -f makefile.mingw. Install the resulting DLLs somewhere |
| in your PATH. You can either keep the headers and import libraries |
| where they are, or install them somewhere else. There are no rules in |
| the makefile.mingws for installing, it is up to you where to put them. |
| |
| Autoconfiscated build |
| ===================== |
| |
| It is also possible to use the auto*, ./configure and libtool |
| mechanism when building with gcc. You should be running Cygwin, or |
| maybe cross-compiling from real Unix, for the configure script to |
| work, obviously. (It might also be possible to use "MSYS", but I |
| haven't checked.) You most probably should have very new auto* and |
| libtool. Tor invokes configure using: |
| |
| CC='gcc -mpentium -fnative-struct' |
| CPPFLAGS='-I/src/libiconv-1.7/include -I/target/include' |
| LDFLAGS='-L/src/libiconv-1.7/lib -L/target/lib' ./configure |
| --with-libiconv --disable-static --prefix=/target |
| --host=i386-pc-mingw32 --enable-maintainer-mode |
| |
| (on a single line) |
| |
| But 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 both compilers generate code that uses the same C |
| runtime library. Thus one either has to manually edit glibconfig.h |
| afterwards, or use the supplied config.h.win32 and |
| glibconfig.h.win32. These have been produced by running configure |
| twice, once using gcc and once using MSVC, and merging the resulting |
| files with diff -D. |
| |
| There might be other hickups when using auto* and configure to build |
| with gcc. Lately Tor has used auto*/configure/libtool exclusively when |
| building GLib, GTK+, GIMP etc on Win32, and it seems to work well |
| (with some patches applied to the current CVS libtool...). |
| |
| The hand-written makefile.{mingw,msc} files, and the stuff in the |
| "build" subdirectory, produce DLLs and import libraries that match |
| what Makefile.am and libtool produces. For GLib, the DLL is called |
| libglib-1.3-15.dll (at GLib 1.3.15), and the import libraries |
| libglib-1.3.dll.a and glib-1.3.lib. Note that the "1.3" is part of the |
| "basename" of the library, it is not something that libtool have |
| tucked on. The -15 suffix is the value of "LT_CURRENT - LT_AGE". The |
| 15 is *not* simply the micro version number of GLib, although, for |
| GLib 1.3.15, it happens to be the same. 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. |
| |
| Building with MSVC |
| ================== |
| |
| 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 |
| |