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.
+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, 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 just type "./configure; make" on Unix, and expect
-things to work as smoothly on Windows.
-
-The following preprocessor macros can be used for conditional
+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 (msvcrt.dll).
+ 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 when
- compiling for Cygwin.
+ 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 (indirectly)
-available in all source files that include <glib.h> or GTK+ headers.
+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
-
-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.
+- __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+
=======================================
-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 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 the libiconv library and GNU
-gettext. Get prebuilt binaries of libiconv (1.9.1 or newer), and
-gettext-runtime (0.12.1 or newer) from your nearest GNU ftp mirror. If
-you use gcc, you will also have to edit the libintl.h file from
-gettext a tiny bit: Change the
-
-# if __GNUC__ >= 2 && !defined __APPLE_CC__ && (defined __STDC__ || defined __cplusplus)
-
-line to
-
-# if __GNUC__ >= 2 && !defined __APPLE_CC__ && !defined __MINGW32__ && (defined __STDC__ || defined __cplusplus)
-
-around line 102.
-
-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.
+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 .
-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 3.2. Version 2.95.3 also works.
-
-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.
+Autoconfiscated build (with gcc)
+================================
-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.
+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.
-Autoconfiscated build
-=====================
+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.
-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 is also possible to use MSYS.
-
-When building from an official source distribution, to be able to
-build DLLs without problems, it might well be necessary to have a
-relatively new version of libtool installed. If so, replace the
-libtool parts included with GLib sources with newer versions by
-running libtoolize --force. After that you want to run aclocal-1.4 and
-autoconf before running configure.
+If you want to use mingw's gcc, install gcc, win32api, binutils and
+MSYS from www.mingw.org.
Tor invokes configure using:
-CC='gcc -mcpu=pentium3' CPPFLAGS='-I/target/include'
- CFLAGS=-O3 LDFLAGS='-L/target/lib' ./configure --with-libiconv
- --disable-static --prefix=/target --host=i386-pc-mingw32
+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
-(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.
+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 (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, and is mutually binary compatible. Thus one either
-has to manually edit glibconfig.h afterwards, or use the supplied
-glibconfig.h.win32. This has been produced by running configure twice,
-once using gcc and once using MSVC, and merging the resulting files
-with diff -D.
-
-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-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.
-
-Building with MSVC
-==================
+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.in
+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.
+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:
ways (for example the Gimp plug-in communication).
]
-Required libraries (not build from cvs)
-==================
- libintl (gnu-intl), libiconv
- libtiff, libpng, zlib, libjpeg
+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
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
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.
|
+- glib
| |
- | +- build : [this module lives in the cvs root dir]
+ | +- 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
| the user needs to know the build order
|
- +- dia : additionally depends on libart_lgpl (in cvs)
+ +- dia : additionally depends on libart_lgpl (in SVN)
| and libxml2 ( see http://www.xmlsoft.org/ )
+- lib
+- app
projects / platform / upstream / glib.git / blobdiff