Commit b123bcf2 authored by Tor Lillqvist's avatar Tor Lillqvist Committed by Tor Lillqvist

Updates.

2003-01-05  Tor Lillqvist  <tml@iki.fi>

	* README.win32: Updates.

	* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
	libm. (Mingw has a dummy libm.a, but the .pc file should be
	useable by MSVC users, too.)
parent dcb78fd4
2003-01-05 Tor Lillqvist <tml@iki.fi>
* README.win32: Updates.
* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
libm. (Mingw has a dummy libm.a, but the .pc file should be
useable by MSVC users, too.)
2003-01-25 Ron Steinke <rsteinke@w-link.net>
(Ancient, binary compatible fixes found sitting in my tree)
......
2003-01-05 Tor Lillqvist <tml@iki.fi>
* README.win32: Updates.
* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
libm. (Mingw has a dummy libm.a, but the .pc file should be
useable by MSVC users, too.)
2003-01-25 Ron Steinke <rsteinke@w-link.net>
(Ancient, binary compatible fixes found sitting in my tree)
......
2003-01-05 Tor Lillqvist <tml@iki.fi>
* README.win32: Updates.
* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
libm. (Mingw has a dummy libm.a, but the .pc file should be
useable by MSVC users, too.)
2003-01-25 Ron Steinke <rsteinke@w-link.net>
(Ancient, binary compatible fixes found sitting in my tree)
......
2003-01-05 Tor Lillqvist <tml@iki.fi>
* README.win32: Updates.
* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
libm. (Mingw has a dummy libm.a, but the .pc file should be
useable by MSVC users, too.)
2003-01-25 Ron Steinke <rsteinke@w-link.net>
(Ancient, binary compatible fixes found sitting in my tree)
......
2003-01-05 Tor Lillqvist <tml@iki.fi>
* README.win32: Updates.
* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
libm. (Mingw has a dummy libm.a, but the .pc file should be
useable by MSVC users, too.)
2003-01-25 Ron Steinke <rsteinke@w-link.net>
(Ancient, binary compatible fixes found sitting in my tree)
......
2003-01-05 Tor Lillqvist <tml@iki.fi>
* README.win32: Updates.
* configure.in: Don't use -lm in TRIO_LIBS on Windows, with no
libm. (Mingw has a dummy libm.a, but the .pc file should be
useable by MSVC users, too.)
2003-01-25 Ron Steinke <rsteinke@w-link.net>
(Ancient, binary compatible fixes found sitting in my tree)
......
......@@ -59,12 +59,13 @@ 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.)
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
=============
......@@ -99,7 +100,7 @@ to use (after some editing).
Building GLib with gcc
======================
Tor uses gcc-2.95.3. Version 2.95.2 will most probably also work.
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
......@@ -123,15 +124,13 @@ 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:
work, obviously. (It should also be possible to use MSYS.) 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
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
--enable-maintainer-mode
(on a single line)
......@@ -146,10 +145,9 @@ 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.
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.
There might be other hickups when using auto* and configure to build
with gcc. Lately Tor has used auto*/configure/libtool exclusively when
......@@ -159,12 +157,13 @@ building GLib, GTK+, GIMP etc on Win32, and it seems to work well
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
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
......@@ -177,7 +176,7 @@ If you would want to use the Cygwin tools to generate a GLib that
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.
and automake.) Tor hasn't tested this in a while, either.
Building with MSVC
==================
......
......@@ -734,7 +734,9 @@ else
AC_DEFINE(HAVE_VASPRINTF,1)
AC_DEFINE(HAVE_C99_VSNPRINTF,1)
AC_DEFINE(HAVE_UNIX98_PRINTF,1)
TRIO_LIBS=-lm
if test "$glib_native_win32" != "yes" ; then
TRIO_LIBS=-lm
fi
fi
AC_SUBST(TRIO_LIBS)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment