Commit 52b5a06d authored by Chun-wei Fan's avatar Chun-wei Fan

Visual C++ Builds: Update README.txt's

Update notes about usage of PCRE and for people attempting to build GLib
on a Chinese, Japanese or Korean locale.
parent b88fdf0b
......@@ -34,16 +34,22 @@ comes with the LibFFI source package for more details on how to build LibFFI
on Visual C++-please note that the mozilla-build package from Mozilla is needed
in order to build LibFFI on Windows.
One may optionally use his/her own PCRE installation by selecting the
(BuildType)_ExtPCRE configuration, but please note the PCRE must be built
with VS10 with unicode support using the /MD (release) or /MDd (debug)
runtime option which corresponds to your GLib build flavour (release, debug).
(These are the defaults set by CMAKE, which is used in recent versions of PCRE.)
Not doing so will most probably result in unexpected crashes in
your programs due to the use of different CRTs. If using a static PCRE
build, add PCRE_STATIC to the "preprocessor definitions".
Note that one may still continue to build with the bundled PCRE by selecting
the (BuildType) configuration.
Please note, although using one's own existing PCRE installation to build GLib
is possible, it is still recommended to build PCRE during the process of building
GLib (i.e. using the Debug or Release configurations), as GLib's bundled PCRE
has been patched to work optimally with GLib. If building against an existing
PCRE is desired, use the(BuildType)_ExtPCRE configurations, but one needs to ensure
that the existing PCRE is:
-Built with VS10
-Unicode support is built in (please see the CMake options for this)
-It is built with the Multithreaded DLL (/MD, for release builds) or the
Multithreaded DLL Debug (/MDd, for debug builds)
If using static builds of PCRE, please add PCRE_STATIC to the "Preprocessor
Definitions" of the glib project settings.
Please be aware that the GLib's regex test program will only pass with PCRE directly
built into GLib.
Set up the source tree as follows under some arbitrary top
folder <root>:
......@@ -73,12 +79,13 @@ built DLLs go into <root>\vs10\<PlatformName>\bin, built LIBs into
project files higher in the stack are supposed to look for them, not
from a specific GLib source tree.
Note: If you see C4819 warnings and you are compiling GLib on a DBCS
Note: If you see C4819 errors and you are compiling GLib on a DBCS
(Chinese/Korean/Japanese) version of Windows, you may need to switch
to an English locale in Control Panel->Region and Languages->System->
Change System Locale, reboot and rebuild to ensure GLib, Pango, GDK-Pixbuf,
ATK and GTK+ is built correctly. This is due to a bug in Visual C++ running
on DBCS locales.
on DBCS locales, and also affects many other opensource projects which are
built with Visual C++, including but not limited to QT and the Mozilla apps.
--Tor Lillqvist <tml@iki.fi>
--Updated by Chun-wei Fan <fanc999@gmail.com>
......@@ -34,16 +34,22 @@ comes with the LibFFI source package for more details on how to build LibFFI
on Visual C++-please note that the mozilla-build package from Mozilla is needed
in order to build LibFFI on Windows.
One may optionally use his/her own PCRE installation by selecting the
(BuildType)_ExtPCRE configuration, but please note the PCRE must be built
with VS9 with unicode support using the /MD (release) or /MDd (debug)
runtime option which corresponds to your GLib build flavour (release, debug).
(These are the defaults set by CMAKE, which is used in recent versions of PCRE.)
Not doing so will most probably result in unexpected crashes in
your programs due to the use of different CRTs. If using a static PCRE
build, add PCRE_STATIC to the "preprocessor definitions".
Note that one may still continue to build with the bundled PCRE by selecting
the (BuildType) configuration.
Please note, although using one's own existing PCRE installation to build GLib
is possible, it is still recommended to build PCRE during the process of building
GLib (i.e. using the Debug or Release configurations), as GLib's bundled PCRE
has been patched to work optimally with GLib. If building against an existing
PCRE is desired, use the(BuildType)_ExtPCRE configurations, but one needs to ensure
that the existing PCRE is:
-Built with VS9
-Unicode support is built in (please see the CMake options for this)
-It is built with the Multithreaded DLL (/MD, for release builds) or the
Multithreaded DLL Debug (/MDd, for debug builds)
If using static builds of PCRE, please add PCRE_STATIC to the "Preprocessor
Definitions" of the glib project settings.
Please be aware that the GLib's regex test program will only pass with PCRE directly
built into GLib.
Set up the source tree as follows under some arbitrary top
folder <root>:
......@@ -73,12 +79,13 @@ built DLLs go into <root>\vs9\<PlatformName>\bin, built LIBs into
project files higher in the stack are supposed to look for them, not
from a specific GLib source tree.
Note: If you see C4819 warnings and you are compiling GLib on a DBCS
Note: If you see C4819 errors and you are compiling GLib on a DBCS
(Chinese/Korean/Japanese) version of Windows, you may need to switch
to an English locale in Control Panel->Region and Languages->System->
Change System Locale, reboot and rebuild to ensure GLib, Pango, GDK-Pixbuf,
ATK and GTK+ is built correctly. This is due to a bug in Visual C++ running
on DBCS locales.
on DBCS locales, and also affects many other opensource projects which are
built with Visual C++, including but not limited to QT and the Mozilla apps.
--Tor Lillqvist <tml@iki.fi>
--Updated by Chun-wei Fan <fanc999@gmail.com>
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