| Tor Lillqvist <tml@iki.fi> |
| Hans Breuer <hans@breuer.org> |
| |
| Note that this document is not really maintained in a serious |
| fashion. Lots of information here might be misleading or outdated. You |
| have been warned. |
| |
| The general parts, and the section about gcc and autoconfiscated |
| build, and about a Visual Studio build are by Tor Lillqvist. The |
| sections about MSVC build with NMAKE is by Hans Breuer. |
| |
| General |
| ======= |
| |
| For prebuilt binaries (DLLs and EXEs) and developer packages (headers, |
| import libraries) of GLib, Pango, GTK+ etc for Windows, go to |
| http://www.gtk.org/download-windows.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 in involved. |
| |
| To build GLib on Win32, you can use either gcc ("mingw") or the |
| Microsoft compiler and tools. For the latter, MSVC6 and later have |
| been used successfully. Also the Digital Mars C/C++ compiler has |
| reportedly been used. |
| |
| You can also cross-compile GLib for Windows from Linux using the |
| cross-compiling mingw packages for your distro. |
| |
| Note that to just *use* GLib on Windows, there is no need to build it |
| yourself. |
| |
| On Windows setting up a correct build environment can be quite a task, |
| especially if you are used to just type "./configure; make" on Linux, |
| and expect things to work as smoothly on Windows. |
| |
| The following preprocessor macros are to 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 (msvcr*.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 by a GLib |
| 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 available in |
| all source files that include <glib.h>. |
| |
| Additionally, there are the compiler-specific macros: |
| - __GNUC__ is defined when using gcc |
| - _MSC_VER is defined when using the Microsoft compiler |
| - __DMC__ is defined when using the Digital Mars C/C++ compiler |
| |
| G_OS_WIN32 implies using the Microsoft C runtime, normally |
| 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. If compiled with Microsoft compilers newer |
| than MSVC6, it also works with their compiler-specific runtimes, like |
| msvcr70.dll or msvcr80.dll. Please note that it's non totally clear if |
| you would be allowed by the license to distrubute a GLib linked to |
| msvcr70.dll or msvcr80.dll, as those are not part of the operating |
| system, but of the MSVC product. msvcrt.dll is part of Windows. |
| |
| Building software that use GLib or GTK+ |
| ======================================= |
| |
| Building software that just *uses* GLib or GTK+ also require to have |
| the right compiler set up the right way. If you intend to use gcc, |
| follow the relevant instructions below in that case, too. |
| |
| Tor uses gcc with the -mms-bitfields flag 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. Such compatibility is desirable. |
| |
| When using the prebuilt GLib DLLs that use msvcrt.dll from code that |
| uses other C runtimes like for example msvcr70.dll, one should note |
| that one cannot use such GLib API that take or returns file |
| descriptors. On Windows, a file descriptor (the small integer as |
| returned by open() and handled by related functions, and included in |
| the FILE struct) is an index into a table local to the C runtime |
| DLL. A file descriptor in one C runtime DLL does not have the same |
| meaning in another C runtime DLL. |
| |
| Building GLib |
| ============= |
| |
| Again, first decide whether you really want to do this. |
| |
| Before building GLib you must also have a GNU gettext-runtime |
| developer package. Get prebuilt binaries of gettext-runtime from |
| http://www.gtk.org/download-windows.html . |
| |
| Autoconfiscated build (with gcc) |
| ================================ |
| |
| Tor uses gcc 3.4.5 and the rest of the mingw utilities, including MSYS |
| from www.mingw.org. Somewhat earlier or later versions of gcc |
| presumably also work fine. |
| |
| Using Cygwin's gcc with the -mno-cygwin switch is not recommended. In |
| theory it should work, but Tor hasn't tested that lately. It can |
| easily lead to confusing situations where one mixes headers for Cygwin |
| from /usr/include with the headers for native software one really |
| should use. Ditto for libraries. |
| |
| If you want to use mingw's gcc, install gcc, win32api, binutils and |
| MSYS from www.mingw.org. |
| |
| Tor invokes configure using: |
| |
| CC='gcc -mtune=pentium3 -mthreads' CPPFLAGS='-I/opt/gnu/include' \ |
| LDFLAGS='-L/opt/gnu/lib -Wl,--enable-auto-image-base' CFLAGS=-O2 \ |
| ./configure --disable-gtk-doc --prefix=$TARGET |
| |
| The /opt/gnu mentioned contains the header files for GNU and (import) |
| libraries for GNU libintl. The build scripts used to produce the |
| prebuilt binaries are included in the "dev" packages. |
| |
| 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. 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 shouldn't be any |
| reason to distribute separate GLib headers and DLLs for gcc and MSVC6 |
| 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 MSVC7 and later (Visual C++ .NET 2003, Visual C++ 2005, Visual C++ |
| 2008 etc) it is preferred to use specific builds of GLib DLLs that use |
| the same C runtime as the code that uses GLib. Such DLLs should be |
| named differently than the ones that use msvcrt.dll. |
| |
| For GLib, the DLL that uses msvcrt.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 added. The -0 suffix is added by libtool |
| and is the value of "LT_CURRENT - LT_AGE". The 0 should *not* be |
| thought to be part of the version number of GLib. 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.ac |
| and libtool documentation. |
| |
| Building with Visual Studio |
| =========================== |
| |
| In an unpacked tarball, you will find in build\win32\vs9 a solution |
| file that can be used to build the GLib DLLs and some auxiliary |
| programs. Read the README.txt file in that folder for more |
| information. Note that you will need a libintl implementation, and |
| zlib. |
| |
| Building with MSVC and NMAKE |
| ============================ |
| |
| If you are building from a GIT snapshot, you will not have all |
| makefile.msc files. You should copy the corresponding makefile.msc.in |
| file to that name, and replace any @...@ strings with the correct |
| value (or use the python script de-in.py from http://hans.breuer.org/gtk/de-in.py). |
| |
| 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 (possibly 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. Of course you need |
| the Microsoft Platform SDK in a recent enough - but not too recent - version. |
| The last PSDK for Visual Studio 6 is: |
| http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm |
| At least install the Core SDK, maybe also the "Tablet PC SDK". |
| |
| |
| 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 svn) |
| ------------------ |
| libintl (gnu-intl), |
| |
| 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 SVN 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 SVN) |
| | and libxml2 ( see http://www.xmlsoft.org/ ) |
| +- lib |
| +- app |
| +- objects |
| +- plug-ins |
| +- python |
| |