luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-11-10 03:16:17 +01:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
Update notes about usage of PCRE and for people attempting to build GLib
on a Chinese, Japanese or Korean locale.
This commit is contained in:
Chun-wei Fan 2014-08-13 09:55:11 +08:00
parent b88fdf0b0f
commit 52b5a06dea
2 changed files with 38 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
build/win32/vs10/README.txt
View File

@ -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>

31
build/win32/vs9/README.txt
View File

@ -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>