=======
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"
+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).
+only. No POSIX (Unix) emulation layer like Cygwin in involved.
-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 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 have been
+used.
-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 without bothering to
-look for prebuilt packages, especially if prebuilt packages tend to
-use installation paths that don't conform to local customs.
+People have also successfully cross-compiled GLib for Win32 from Linux
+using the cross-mingw packages.
+
+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 Unix,
+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
- 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
- __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.
+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.13.1 or newer) from www.gimp.org/win32/downloads.html.
+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.3.1. Somewhat earlier or later versions presumably also
-work.
+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.
-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.
+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, 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.
+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-gtk-doc --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. 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
+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 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 is *not* part of the version number of
+GLib, although, for GLib 2.x.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.
+docs/reference/glib/html/glib-cross-compiling.html (part of the GLib
+reference manual) for more information.
Building with MSVC
==================
-If you are building from a CVS snapshot, you will not have any
+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.
+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 (after some
+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"
(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)
+Required libraries (not build from svn)
------------------
- libintl (gnu-intl), libiconv
- libtiff, libpng, zlib, libjpeg
+ libintl (gnu-intl),
are available pre-built from the website mentioned above.
|
+- 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