Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Simplify and update wxMSW build instructions.

Browse Source 
Keep the most important points, remove the obsolete stuff.

Also get rid of 99% of the contents of BuildSVN.txt which simply duplicated
the information from the other files.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH@75080 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Vadim Zeitlin
2013-10-27 15:33:39 +00:00
parent f1d5e29800
commit d06a91910e
2 changed files with 221 additions and 710 deletions
Download Patch File Download Diff File Expand all files Collapse all files

247
BuildSVN.txt
View File

@@ -2,243 +2,12 @@
How to build the sources from SVN How to build the sources from SVN
------------------------------------------------------------------------ ------------------------------------------------------------------------
Please use the install.txt files in docs/gtk, docs/msw, docs/motif, docs/mac Before building from svn sources under Windows, you need to copy the
etc. alongside these instructions. file include/wx/msw/setup0.h to include/wx/msw/setup.h. This is
necessary in order to allow having local modifications to the latter
I) Windows using plain makefiles file without showing it as modified, as it is not under version
---------------------------------------- control.
a) If using Microsoft Visual C++ 5.0 or 6.0
Ensure that the command-line compiler and tools (including
nmake) are installed and ready to run. Depending on your
installation there may be a batch file (commonly named VCVARS32.BAT)
that needs to be run to set correct environment variables and PATH entries.
Continue with item c) below.
b) If using the MinGW or Cygwin compilers
You can get MinGW from http://www.mingw.org/
Cygwin is available at http://www.cygwin.com/
If you are using Cygwin or MinGW together with the MSYS environment, you
can build the library using configure (see "Unix ports" and
"Windows using configure" below). You can also
build wxWidgets without configure using native makefile, but only with
MinGW. Using Cygwin together with Windows makefile is no longer supported.
If building with MinGW without configure:
-> Set your path so that it includes the directory
where your compiler and tools reside
-> Make sure you have GNU Make installed. It must be Windows native version.
Download it from http://www.mingw.org, the executable will be called
mingw32-make.exe.
-> Modern version of MinGW is required; preferably MinGW 2.0 (with gcc3),
but MinGW with gcc-2.95.3 will suffice. If you are using 2.95, you will
have to change variable GCC_VERSION in config.gcc (see msw/install.txt
for details).
If using configure, Unix instructions apply.
c) Build instructions
Assuming that you installed the wxWidgets sources into c:\wxWidgets:
-> Copy c:\wxWidgets\include\wx\msw\setup0.h
to c:\wxWidgets\include\wx\msw\setup.h
-> Edit c:\wxWidgets\include\wx\msw\setup.h to choose
the features you would like to compile wxWidgets with[out].
and std iostreams are disabled with
#define wxUSE_STD_IOSTREAM 0
-> type: cd c:\wxWidgets\build\msw
-> type: make -f makefile.gcc (if using GNU tools)
or type: nmake -f makefile.vc (if using MS VC++)
etc.
See also docs/msw/install.txt for additional compilation options.
d) Borland (including free command line tools)
Download tools from http://www.borland.com/downloads/
See docs/msw/install.txt for details; in brief:
-> type cd c:\wxWidgets\build\msw
-> type make -f makefile.bcc
You can customize many things in the build process, detailed description is
in docs/msw/install.txt.
II) Unix ports
--------------
Building wxGTK or wxMotif completely without configure
won't ever work, but there is now a new makefile system
that works without libtool and automake, using only
configure to create what is needed.
In order to create configure, you need to have the
GNU autoconf package (version > 2.54) installed
on your system and type run "autoconf" in the base
directory (or run the autogen.sh script in the same
directory, which just calls autoconf). Note that you usually don't
need to do this because configure is included in SVN.
Set WXWIN environment variable to the base directory such
as ~/wxWidgets (this is actually not really needed).
-> type: export WXWIN=~/wxWidgets
-> type: md mybuild
-> type: cd mybuild
-> type: ../configure --with-motif
or type: ../configure --with-gtk
-> type: make
-> type: su <type root password>
-> type: make install
-> type: ldconfig
-> type: exit
Call configure with --disable-shared to create a static
library. Calling "make uninstall" will remove the installed
library and "make dist" will create a distribution (not
yet complete).
III) Windows using configure
----------------------------------------
wxWidgets can be built on Windows using MSYS (see
http://www.mingw.org/), which is a POSIX build environment
for Windows. With MSYS you can just ./configure && make (see also VII,
Unix->Windows cross-compiling using configure).
Of course, you can also build the library using plain makefiles (see
section I).
V) MacOS X using configure and the Developer Tools
----------------------------------------
You need to have the Developer Tools installed. If this is not the case,
you will need to register at the Apple Developer web site (this is a free
registration) in order to download the Developer Tools installer.
In order to create configure, you need to have the
GNU autoconf package (version >= 2.54) installed
on your system and type run "autoconf" in the base
directory (or run the autogen.sh script in the same
directory, which just calls autoconf).
-> type: mkdir macbuild
-> type: cd macbuild
-> type: ../configure --with-mac
or type: ../configure
-> type: make
VI) OS/2
----------------------------------------
No notes.
VII) Unix->Windows cross-compiling using configure
--------------------------------------------------
First you'll need a cross-compiler; linux glibc binaries of MinGW and
Cygwin (both based on egcs) can be found at
ftp://ftp.objsw.com/pub/crossgcc/linux-x-win32. Alternative binaries,
based on the latest MinGW release can be found at
http://members.telering.at/jessich/mingw/mingwcross/mingw_cross.html
Otherwise you can compile one yourself.
[ A Note about Cygwin and MinGW: the main difference is that Cygwin
binaries are always linked against cygwin.dll. This dll encapsulates most
standard Unix C extensions, which is very handy if you're porting unix
software to windows. However, wxMSW doesn't need this, so MinGW is
preferable if you write portable C(++). ]
You might want to build both Unix and Windows binaries in the same source
tree; to do this make subdirs for each e.g. unix and win32. If you've
already build wxWidgets in the main dir, do a 'make distclean' there,
otherwise configure will get confused. (In any case, read the section 'Unix
using configure' and make sure you're able to build a native wxWidgets
library; cross-compiling errors can be pretty obscure and you'll want to be
sure that your configure setup is basically sound.)
To cross compile the windows library, do
-> cd win32
(or whatever you called it)
Now run configure. There are two ways to do this
-> ../configure --host=i586-mingw32 --build=i586-linux --with-mingw
where --build= should read whatever platform you're building on. Configure
will notice that build and host platforms differ, and automatically prepend
i586-mingw32- to gcc, ar, ld, etc (make sure they're in the PATH!).
The other way to run configure is by specifying the names of the binaries
yourself:
-> CC=i586-mingw32-gcc CXX=i586-mingw32-g++ RANLIB=i586-mingw32-ranlib \
DLLTOOL=i586-mingw32-dlltool LD=i586-mingw32-ld NM=i586-mingw32-nm \
../configure --host=i586-mingw32 --with-mingw
(all assuming you're using MinGW)
By default this will compile a DLL, if you want a static library,
specify --disable-shared.
Type
-> make
and wait, wait, wait. Don't leave the room, because the minute you do there
will be a compile error :-)
NB: if you are using a very old compiler you risk to get quite a few warnings
about "ANSI C++ forbids implicit conversion from 'void *'" in all places
where va_arg macro is used. This is due to a bug in (some versions of)
MinGW headers which may be corrected by upgrading your compier,
otherwise you might edit the file
${install_prefix}/lib/gcc-lib/i586-mingw32/egcs-2.91.57/include/stdarg.h
(instead of egcs-2.91.57 you may have something different), searching for
the lines
/* Define __gnuc_va_list. */
#ifndef __GNUC_VA_LIST
#define __GNUC_VA_LIST
#if defined(__svr4__) || defined(_AIX) || defined(_M_UNIX) || defined(__NetBSD__)
typedef char *__gnuc_va_list;
#else
typedef void *__gnuc_va_list;
#endif
#endif
and adding "|| defined(_WIN32)" to the list of platforms on which
__gnuc_va_list is char *.
If this is successful, you end up with a wx23_2.dll/libwx23_2.a in win32/lib
(or just libwx_msw.a if you opted for a static build).
Now try building the minimal sample:
-> cd samples/minimal
-> make
and run it with wine, for example (or copy to a Windows box)
-> wine minimal.exe
If all is well, do an install; from win32
-> make install
Native and cross-compiled installations can co-exist peacefully
(as long as their widget sets differ), except for wx-config. You might
want to rename the cross-compiled one to i586-mingw32-wx-config, or something.
Cross-compiling TODO:
---------------------
- resource compiling must be done manually for now (should/can we link the
default wx resources into libwx_msw.a?) [ No we can't; the linker won't
link it in... you have to supply an object file ]
- static executables are HUGE -- there must be room for improvement.
After doing this, please proceed with the build as with any official
release, i.e. follow the instructions in the install.txt file in
docs/gtk, docs/msw and so on.

680
docs/msw/install.txt
View File

@@ -1,27 +1,9 @@
Installing wxWidgets for Windows Installing wxWidgets for Windows
----------------------------------------------------------- --------------------------------
This is wxWidgets for Microsoft Windows 9x/ME, Windows NT This is wxWidgets for Microsoft Windows 9x/ME, Windows NT
and later (2000, XP, Vista, 7, etc) and Windows CE. and later (2000, XP, Vista, 7, 8, etc) including both 32 bit and 64
bit versions.
These installation notes can be found in docs/msw/install.txt
in your wxWidgets distribution.
IMPORTANT NOTE: If you experience problems installing, please
re-read these instructions and other related files (changes.txt,
readme.txt, FAQ) carefully before posting to wx-users list.
If you are sure that you found a bug, please report it at
wxWidgets Trac:
http://trac.wxwidgets.org/newticket
Please notice that often trying to correct the bug yourself is the
quickest way to fix it. Even if you fail to do it, you may
discover valuable information allowing us to fix it while doing
it. We also give much higher priority to bug reports with patches
fixing the problems so this ensures that your report will be
addressed sooner.
Table of Contents: Table of Contents:
@@ -34,27 +16,37 @@ Table of Contents:
Installation Installation
============ ============
Please simply uncompress the .zip file manually into any directory. If you are using one of the supported compilers, you can download the
However we advise avoiding using directories with spaces in their pre-built in binaries from
names (notably "C:\Program Files") as this risks creating problems
https://sourceforge.net/projects/wxwindows/files/3.0.0/binaries/
or
ftp://ftp.wxwidgets.org/pub/3.0.0/binaries/
In this case, just uncompress the binaries archive under any directory
and skip to "Building Applications Using wxWidgets" part.
Otherwise, or if you want to build a configuration of the library
different from the default one, you need to build the library from
sources before using it.
The first step, which you may have already performed, unless you are
reading this file online, is to download the source archive and
uncompress it in any directory. It is strongly advised to avoid using
spaces in the name of this directory, i.e. notably do *not* choose a
location under "C:\Program Files", as this risks creating problems
with makefiles and other command-line tools. with makefiles and other command-line tools.
After choosing the directory location, please define WXWIN environment
In the majority of cases, you don't need to change the default variable containing the full path to this directory. While this is not
library build configuration. If you wish to change some of the build actually required, this makes using the library more convenient and
options you need to edit the include/wx/msw/setup.h file enabling or this environment variable is used in the examples below.
disabling the features you would like to compile wxWidgets with[out].
NB: If you checked your sources from version control repository and NB: If you checked your sources from version control repository and
didn't obtain them from a release file, the file above doesn't didn't obtain them from a release file, you also need to copy
exist and you will need to copy include/wx/msw/setup0.h to include/wx/msw/setup0.h to include/wx/msw/setup.h.
include/wx/msw/setup.h.
Notice that this file is later copied into a directory under lib for
each of the build configurations which allows to have different
build options for different configurations too.
See "Configuring the Build" section for more information.
Building wxWidgets Building wxWidgets
@@ -64,224 +56,168 @@ The following sections explain how to compile wxWidgets with each supported
compiler, see the "Building Applications" section about the instructions for compiler, see the "Building Applications" section about the instructions for
building your application using wxWidgets. building your application using wxWidgets.
Search for one of Microsoft/Borland/Watcom/Symantec/Cygwin/Mingw32 keywords
to quickly locate the instructions for your compiler. Notice that the primary
compilers for wxWidgets under MSW are Microsoft Visual C++ and GNU g++, other
compilers are more rarely tested and might not work so please consider using
one of these two if possible.
All makefiles and project are located in build\msw directory. All makefiles and project are located in build\msw directory.
Where Compiled Files are Stored
-------------------------------
After successful compilation you'll find the libraries in a subdirectory
of lib directory named after the compiler and DLL/static settings.
A couple of examples:
lib\vc_lib VC++ compiled static libraries
lib\vc_dll VC++ DLLs
lib\bcc_lib Static libraries for Borland C++
lib\wat_dll Watcom C++ DLLs
Names of compiled wxWidgets libraries follow this scheme: libraries that don't
depend on GUI components begin with "wxbase" followed by a version number and,
optionally, letters indicating Unicode compilation ('u') and a debug build ('d').
The last component is the name of the wxWidgets component (unless you build the
library as single monolithic library; look for "Configuring the Build" below).
This is a typical set of release ANSI build libraries (release versions on
left, debug on right side):
wxbase29.lib wxbase29d.lib
wxbase29_net.lib wxbase29d_net.lib
wxbase29_xml.lib wxbase29d_xml.lib
wxmsw29_core.lib wxmsw29d_core.lib
wxmsw29_html.lib wxmsw29d_html.lib
wxmsw29_adv.lib wxmsw29d_adv.lib
Their Unicode debug counterparts in wxUniversal build would be
wxbase29ud.lib
wxbase29ud_net.lib
wxbase29ud_xml.lib (notice these libs are same for wxUniv and wxMSW)
wxmswuniv29ud_core.lib
wxmswuniv29ud_html.lib
wxmswuniv29ud_adv.lib
These directories also contain a subdirectory with the wx/setup.h header. This
subdirectory is named after the port, Unicode, wxUniv and debug settings and
you must add it to the include paths when compiling your application. Some
examples:
lib\vc_lib\msw\wx\setup.h VC++ static, wxMSW
lib\vc_lib\mswud\wx\setup.h VC++ static, wxMSW, Unicode, debug
lib\vc_lib\mswunivd\wx\setup.h VC++ static, wxUniversal, debug
Below are compiler specific notes followed by customizing instructions that
apply to all compilers (search for "Configuring the Build").
Microsoft Visual C++ Compilation Microsoft Visual C++ Compilation
---------------------------------------------------------------- ----------------------------------------------------------------
You may wish to visit http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide * From command line using the provided makefiles:
for a more informal and detailed description of the process summarized below.
Please note that currently ready to use projeect files are provided for VC++ 0. Open a "Visual Studio Command Prompt" window shortcut to which
versions 6 through to 9 (also known as 6, 2003, 2005 and 2008). For VC++ 10 and must have been installed to the "Start" menu or the "Start" screen
11 (2010 and 2012, respectively), you will need to import the existing VC9 by MSVS installation.
project files.
Using project files (VC++ 6 and later): 1. Change directory to %WXWIN%\build\msw and type
1. Unarchive wxWidgets-x.y.z-vc.zip, the VC++ 6 project > nmake /f makefile.vc
makefiles (already included in wxMSW-x.y.z.zip and the setup version).
2. Open build\msw\wx.dsw, which has configurations for static
compilation or DLL compilation, and each of these available in
Unicode/ANSI, Debug/Release and wxUniversal or native variations.
Choose the Win32 Debug or Win32 Release configuration (or any other that
suits your needs) and use Batch Build to compile _all_ projects. If you
know you won't need some of the libraries (e.g. the HTML part), you don't have
to compile it. It will also produce similar variations on jpeg.lib,
png.lib, tiff.lib, zlib.lib, and regex.lib.
If you want to build DLL configurations in wx.dsw project you unfortunately to build wxWidgets in the default debug configuration as a static
need to build them in the proper order (jpeg, png, tiff, zlib, regex, expat, library. You can also do
base, net, core, gl, html, media, qa, adv, xrc, aui, richtext,
propgrid) manually because VC6 doesn't always respect the correct build order.
Alternatively, use the special wx_dll.dsw project which adds the > nmake /f makefile.vc BUILD=release
dependencies to force the correct order (but, because of this, doesn't work
for the static libraries) or simply redo the build several times until all
DLLs are linked correctly.
3. Open a sample project file, choose a configuration such as
Win32 Debug using Build | Set Active Configuration..., and compile.
The project files don't use precompiled headers, to save disk
space, but you can switch PCH compiling on for greater speed.
NOTE: you may also use samples/samples.dsw to access all
sample projects without opening each workspace individually.
You can use the Batch Build facility to make several samples
at a time.
Using makefiles: to build a release version or
1. Change directory to build\msw. Type: > nmake /f makefile.vc BUILD=release SHARED=1
'nmake -f makefile.vc' to build a release DLL version. Finally, you can also add
"TARGET_CPU=X64" to nmake command line to build Win64 versions
(this only works if you are using a 64 bit compiler, of course).
to make the wxWidgets core library as release DLL. See "Configuring the Build" for more information about the
See "Configuring the Build" for instruction how to build debug or static additional parameters that can be specified on the command line.
libraries.
2. Change directory to samples and type 'nmake -f makefile.vc' 2. To verify your build, change the directory to samples\minimal and
to make all the samples. You can also make them individually. run the same nmake command (with the same parameters there), this
should create a working minimal wxWidgets sample.
Makefile notes: 3. If you need to rebuild, use "clean" target first or "nmake /a".
Use the 'clean' target to clean all objects, libraries and
executables.
Note (1): if you wish to use templates, please edit * From the IDE using the provided project files:
include\wx\msw\setup.h and set wxUSE_DEBUG_NEW_ALWAYS to 0.
Without this, the redefinition of 'new' will cause problems in
the headers. Alternatively, #undef new before including template headers.
You will also need to set wxUSE_IOSTREAMH to 0 if you will be
using templates, to avoid the non-template stream files being included
within wxWidgets.
Note (2): libraries and applications generated with makefiles and Ready to use project files are provided for VC++ versions 6, 7, 8, 9
project files are now (hopefully) compatible where static libraries and 10 (also known as MSVS 6, 2003, 2005, 2008 and 2010 respectively).
are concerned, but please exercise caution nevertheless and if For VC++ 11 (2012, respectively), you need to import the existing VC10
possible, use one method or the other. project files into VC11 IDE first.
Note (3): some crash problems can be due to inconsistent compiler Simply open wx_vcN.sln (for N=7, 8, 9 or 10) or wx.dsw (for VC6) file,
options. If strange/weird/impossible things start to happen please select the appropriate configuration (Debug or Release, static or DLL)
check (dumping IDE project file as makefile and doing text comparison and build the solution. Notice that when building a DLL configuration,
if necessary) that the project settings, especially the list of defined you may need to perform the build several times because the projects
symbols, struct packing, etc. are exactly the same for all items in are not always built in the correct order, and this may result in link
the project. After this, delete everything (including PCH) and recompile. errors. Simply do the build again, up to 3 times, to fix this.
Note (4): to create your own IDE files, copy .dsp and .dsw Notice that x64 configurations are only included in VC10 project
files from an existing wxWidgets sample and adapt them, or currently. If you want to build Win64 libraries with the previous
visit http://wiki.wxwidgets.org/Microsoft_Visual_C%2B%2B_Guide. compiler versions, the simplest solution is to use the makefiles as
described above.
Microsoft Visual C++ Compilation for 64-bit Windows
Cygwin/MinGW Compilation
---------------------------------------------------------------- ----------------------------------------------------------------
Visual Studio 2005 includes 64-bit compilers, though they are not installed by wxWidgets supports Cygwin, MinGW, MinGW-w64 and TDM-GCC tool chains under
default; you need to select them during the installation. Both native 64-bit Windows. They can be downloaded from:
compilers and 32-bit hosted cross compilers are included, so you do not need a
64-bit machine to use them (though you do to run the created executables).
Visual C++ Express Edition does not include 64-bit compilers.
64-bit compilers are also available in various SDKs, for example http://www.cygwin.com/
the .NET Framework SDK: http://www.mingw.org/
http://msdn.microsoft.com/netframework/programming/64bit/devtools/ http://mingw-w64.sourceforge.net/
http://tdm-gcc.tdragon.net/
Using project files: respectively. Please retrieve and install the latest version of your preferred
tool chain by following the instructions provided by these packages. Notice
that Cygwin includes both native Cygwin compiler, which produces binaries that
require Cygwin during run-time, and MinGW[-w64] cross-compilers which can still
be used in Cygwin environment themselves but produce plain Windows binaries
without any special run-time requirements. You will probably want to use the
latter for developing your applications.
1. Open the solution file for the version you use: build\msw\wx_vc8.sln or If using MinGW, you can download the add-on MSYS package to provide Unix-like
wx_vc9.sln. tools that you'll need to build wxWidgets using configure.
2. To add 64-bit targets, go to the 'Build' menu and choose 'Configuration C++11 note: If you want to compile wxWidgets in C++11 mode, you currently have
Manager...'. In the 'Active solution platform' drop down choose '<new>', to use -std=gnu++11 switch as -std=c++11 disables some extensions
then you can choose either 'Itanium' or 'x64'. that wxWidgets relies on. I.e. please use CXXFLAGS="-std=gnu++11".
For more detailed instructions see: All of these tool chains can be used either with Unix-like configure+make build
http://msdn2.microsoft.com/en-us/library/9yb4317s(en-us,vs.80).aspx process (preferred) or with the provided makefile.gcc makefiles without using
configure:
Note: 64-bit targets created this way will use the build directory of the * Using configure
corresponding 32-bit target for some files. Therefore after building
for one CPU it is necessary to clean the build before building the
equivalent target for another CPU. We've reported the problem to MS
but they say it is not possible to fix it.
3. To build, go to the 'Build' menu and choose 'Batch Build...'. Tick all the This method works in exactly the same way as under Unix systems,
all the 'x64|Debug' or all the 'Itanium|Debug' projects, and click 'Build'. including OS X, and requires a Unix-like environment to work, i.e.
either MSYS or Cygwin.
This will build a debug version of the static libs. The section above on 0. Open MSYS or Cygwin shell prompt.
Visual C++ in general has more information about adjusting the settings to
build other configurations.
4. To compile one of the samples open one of the sample projects, such as 1. Create a build directory: it is is strongly recommended to not
samples\minimal\minimal_vc7.vcproj. Visual Studio will convert the project as in build the library in the directory containing the sources ($WXWIN)
step 1, then add a 64-bit target as in step 2, and build. but to create a separate build directory instead. The build
directory can be placed anywhere (using the fastest available disk
may be a good idea), but in this example we create it as a
subdirectory of the source one:
Using makefiles: $ cd $WXWIN
$ mkdir build-debug
1. Open a 64-bit build command prompt, for either x64 or Itanium. Change 2. Run configure passing it any of the options shown by "configure
directory to build\msw. Then for x64 type: --help". Notice that configure builds shared libraries by default,
use --disable-shared to build static ones. For example:
nmake -f makefile.vc TARGET_CPU=X64 $ ../configure --enable-debug
or for Itanium: 3. Build the library:
nmake -f makefile.vc TARGET_CPU=IA64 $ make
This will build a debug version of wxWidgets DLLs. See "Configuring the 4. Test the library build by building the minimal sample:
build" for instruction how to build other configurations such as a release
build or static libraries.
2. Change to the directory of one of the samples such as samples\minimal. Type $ cd samples/minimal
the same command used to build the main library, for example for x64: $ make
nmake -f makefile.vc TARGET_CPU=X64 5. Optionally install the library in a global location
Notes: $ make install
The versions of the VC++ 8 compiler included with some SDKs requires an Notice that there is not much benefice to installing under Windows
additional library to be linked or the following error is received. so this step can usually be omitted.
LNK2001 unresolved external symbol __security_check_cookie
If you receive this error add bufferoverflowu.lib to link, e.g.: * Using plain makefiles:
NOTE: The makefile.gcc makefiles are for compilation under MinGW using
Windows command interpreter (command.com/cmd.exe), they won't work
if you use Unix shell, as is the case with MSYS. Follow the instructions
for using configure above instead if you prefer to use Unix shell.
0. Open DOS command line window (cmd.exe, *not* Bash sh.exe).
1. Change directory to %WXWIN%\build\msw and type
> mingw32-make -f makefile.gcc
to build wxWidgets in the default debug configuration as a static
library. Add "BUILD=release" and/or "SHARED=1" to build the library
in release configuration and/or as a shared library instead of the
default static one.
2. To verify your build, change the directory to samples\minimal and
run the same mingw32-make command (with the same parameters there),
this should create a working minimal wxWidgets sample.
3. If you need to rebuild, use "clean" target first.
nmake -f makefile.vc TARGET_CPU=X64 LDFLAGS=bufferoverflowu.lib
See http://support.microsoft.com/?id=894573 for more information.
Borland C++ Compilation Borland C++ Compilation
---------------------------------------------------------------- ----------------------------------------------------------------
WARNING: Borland instructions are out of date, please send us your
corrections if you are using it with wxWidgets 3.0.
The minimum version required is 5.5 (last version supported by BC++ 5.0 was The minimum version required is 5.5 (last version supported by BC++ 5.0 was
2.4.2), which can be downloaded for free from: 2.4.2), which can be downloaded for free from:
http://www.borland.com/products/downloads/download_cbuilder.html http://www.borland.com/products/downloads/download_cbuilder.html
@@ -344,179 +280,55 @@ the following preprocessor directive:
(check the samples -- e.g., \wx2\samples\minimal\minimal.cpp -- for (check the samples -- e.g., \wx2\samples\minimal\minimal.cpp -- for
more details) more details)
Watcom C++ 10.6/11 and OpenWatcom Compilation
----------------------------------------------------------------
1. Change directory to build\msw. Type 'wmake -f makefile.wat' to
make the wxWidgets core library.
2. Change directory to samples\minimal and type 'wmake -f makefile.wat'
to make this sample. Repeat for other samples of interest.
Note (1): if variant.cpp is compiled with date/time class options, the linker
gives up. So the date/time option is switched off for Watcom C++.
Also, wxAutomationObject is not compiled with Watcom C++ 10.
Note (2): RawBitmaps won't work at present because they use unsupported template
classes
Note (3): if Watcom can't read the precompiled header when building a sample,
try deleting .pch files in build\msw\wat_* and compiling
the sample again.
Note (4): wxUSE_STD_STRING is disabled in wx/string.h for Watcom as this
compiler doesn't come with standard C++ library headers by default.
If you install STLPort or another STL implementation, you'll need to
edit wx/string.h and remove the check for Digital Mars in it (search
for __WATCOM__).
Cygwin/MinGW Compilation
----------------------------------------------------------------
wxWidgets supports Cygwin, MinGW, MinGW-w64 and TDM-GCC tool chains under
Windows. They can be downloaded from:
http://www.cygwin.com/
http://www.mingw.org/
http://mingw-w64.sourceforge.net/
http://tdm-gcc.tdragon.net/
respectively. Please retrieve and install the latest version of your preferred
tool chain by following the instructions provided by these packages. Notice
that Cygwin includes both native Cygwin compiler, which produces binaries that
require Cygwin during run-time, and MinGW[-w64] cross-compilers which can still
be used in Cygwin environment themselves but produce plain Windows binaries
without any special run-time requirements. You will probably want to use the
latter for developing your applications.
If using MinGW, you can download the add-on MSYS package to provide Unix-like
tools that you'll need to build wxWidgets using configure.
C++11 note: If you want to compile wxWidgets in C++11 mode, you currently have
to use -std=gnu++11 switch as -std=c++11 disables some extensions
that wxWidgets relies on. I.e. please use CXXFLAGS="-std=gnu++11".
All of these tool chains can be used either with Unix-like configure+make build
process (preferred) or with the provided makefile.gcc makefiles without using
configure:
Using makefiles Directly
----------------------------------------------------------------
NOTE: The makefile.gcc makefiles are for compilation under MinGW using
Windows command interpreter (command.com/cmd.exe), they won't work
if you use Unix shell, as is the case with MSYS. Follow the instructions
for using configure below instead in this case.
Use the makefile.gcc files for compiling wxWidgets and samples,
e.g. to compile a debugging version of wxWidgets:
> cd c:\wx\build\msw
> mingw32-make -f makefile.gcc BUILD=debug
> cd c:\wx\samples\minimal
> mingw32-make -f makefile.gcc BUILD=debug
(See below for more options.)
Notice that Windows command interpreter (cmd.exe) and mingw32-make must be
used, using Bash (sh.exe) and make.exe from MSYS will only work when using
configure-based build procedure described below!
You can also use the 'strip' command to reduce executable/dll size (note that
stripping an executable/dll will remove debug information!).
All targets have 'clean' targets to allow removal of object files
and other intermediate compiler files.
Using configure
----------------------------------------------------------------
Instead of using the makefiles, you can use the configure
system to generate appropriate makefiles, as used on Unix
and Mac OS X systems.
Change directory to the root of the wxWidgets distribution,
make a build directory, and run configure and make in this directory.
For example:
$ cd $WXWIN
$ mkdir build-debug
$ cd build-debug
$ # Optionally use --disable-shared for static linking
$ ../configure --enable-debug
$ make
$ make install # This step is optional
$ cd samples/minimal
$ make
$ ./minimal.exe
DigitalMars C++ Compilation
----------------------------------------------------------------
Digital Mars compiler is no longer updated as the project is discontinued.
wxWidgets 2.8 was the last version to compile with this compiler.
Configuring the Build Configuring the Build
================================================================ ================================================================
So far the instructions only explain how to build release DLLs of wxWidgets NOTE: If you use configure to build the library with Cygwin/MinGW, the
and did not cover any configuration. It is possible to change many aspects of contents of this section does not apply, just pass the arguments
the build, including debug/release and static/dynamic settings. to configure directly in this case.
Notice that in the previous versions of wxWidgets it was possible to build the Library configuration
library in either ANSI or Unicode mode but in wxWidgets 2.9 and later only a
single, combined, build mode exists. It is still possible to set UNICODE=0 to
disable Unicode support entirely but it is strongly not recommended and should
be never necessary.
Changing the Settings
---------------------------------------------------------------- ----------------------------------------------------------------
There are two ways to modify the settings: either by passing the values as While it is never necessary to do it, you may want to change some of
arguments when invoking make or by editing build\msw\config.$(compiler) file the options in the include/wx/msw/setup.h file before building wxWidgets.
where $(compiler) is same extension as the makefile you use has (see below). This file is heavily commented, please read it and enable or disable
The latter is good for setting options that never change in your development the features you would like to compile wxWidgets with[out].
process (e.g. GCC_VERSION or VENDOR). If you want to build several versions of
wxWidgets and use them side by side, the former method is better. Settings in
config.* files are shared by all makefiles (samples, contrib, main library),
but if you pass the options as arguments, you must use same arguments you used
for the library when building samples or contrib libraries!
Examples of invoking make in Unicode debug build (other options described Notice that this file is later copied into a directory under lib for
below are set analogically): each of the build configurations which allows to have different
build options for different configurations too if you edit any
configuration-specific file.
Makefile parameters
----------------------------------------------------------------
When building using makefiles, you can specify many build settings
(unlike when using the project files where you are limited to choosing
just the configuration and platform). This can be done either by
passing the values as arguments when invoking make or by editing
build\msw\config.$(compiler) file where $(compiler) is same extension
as the makefile you use has (see below). The latter is good for
setting options that never change in your development process (e.g.
GCC_VERSION or VENDOR). If you want to build several versions of
wxWidgets and use them side by side, the former method is better.
Settings in config.* files are shared by all makefiles (including the
samples), but if you pass the options as arguments, you must use same
arguments you used for the library when building samples!
For example, to build the library in release mode you can either
change the "BUILD" variable definition in build\msw\config.$(compiler)
or use
Visual C++:
> nmake -f makefile.vc BUILD=debug > nmake -f makefile.vc BUILD=debug
Borland C++:
> make -f makefile.bcc -DBUILD=debug
(Note that you have to use -D to set the variable, unlike in other make
tools!)
Watcom C/C++:
> wmake -f makefile.wat BUILD=debug
MinGW using native makefiles:
> mingw32-make -f makefile.gcc BUILD=debug > mingw32-make -f makefile.gcc BUILD=debug
MinGW using configure: depending on the compiler used.
> ./configure --enable-debug
(see ./configure --help on details; configure is not covered in this
section)
Cygwin using configure: The full list of the build settings follows:
> ./configure --disable-precomp-headers --enable-debug
(use --disable-precomp-headers if Cygwin doesn't support precompiled
headers)
Brief explanation of options and possible values is in every
build\msw\config.* file; more detailed description follows.
Basic Options
----------------------------------------------------------------
BUILD=release BUILD=release
Builds release version of the library. It differs from default 'debug' in Builds release version of the library. It differs from default 'debug' in
@@ -534,16 +346,13 @@ UNICODE=0
systems and can't use MSLU (which requires MSLU=1) for some reason. systems and can't use MSLU (which requires MSLU=1) for some reason.
This option affect name of the library ('u' is appended in the default This option affect name of the library ('u' is appended in the default
Unicode build) and the directory where the library and setup.h are store Unicode build) and the directory where the library and setup.h are stored
(ditto). (ditto).
WXUNIV=1 WXUNIV=1
Build wxUniversal instead of native wxMSW (see Build wxUniversal instead of native wxMSW (see
http://www.wxwidgets.org/wxuniv.htm for more information). http://www.wxwidgets.org/wxuniv.htm for more information).
Advanced Options
----------------------------------------------------------------
MONOLITHIC=1 MONOLITHIC=1
Starting with version 2.5.1, wxWidgets has the ability to be built as Starting with version 2.5.1, wxWidgets has the ability to be built as
several smaller libraries instead of single big one as used to be the case several smaller libraries instead of single big one as used to be the case
@@ -554,22 +363,13 @@ MONOLITHIC=1
USE_GUI=0 USE_GUI=0
Disable building GUI parts of the library, build only wxBase components used Disable building GUI parts of the library, build only wxBase components used
by console applications. Note that if you leave USE_GUI=1 then both wxBase by console applications. Note that if you leave USE_GUI=1 then both wxBase
and GUI libraries are built. If you are building monolithic library, then and GUI libraries are built.
you should set wxUSE_GUI to 1 in setup.h.
USE_OPENGL=1 USE_$(LIBRARY)=0
Build wxmsw29_gl.lib library with OpenGL integration class wxGLCanvas. Do not build the corresponding library (all libraries are built by
You must also modify your setup.h to #define wxUSE_GLCANVAS 1. Note that default). Library which can be disabled in this way are: AUI, HTML,
OpenGL library is always built as additional library, even in monolithic MEDIA, GL (the option name is USE_OPENGL for this one), PROPGRID,
build! QA, RIBBON, RICHTEXT, STC, WEBVIEW, XRC.
USE_HTML=0
Do not build wxHTML library. If MONOLITHIC=1, then you must also
#define wxUSE_HTML 1 in setup.h.
USE_XRC=0
Do not build XRC resources library. If MONOLITHIC=1, then you must also
#define wxUSE_HTML 1 in setup.h.
RUNTIME_LIBS=static RUNTIME_LIBS=static
Links static version of C and C++ runtime libraries into the executable, so Links static version of C and C++ runtime libraries into the executable, so
@@ -606,6 +406,16 @@ DEBUG_INFO=1
omitted or set to 'default' its value is determined the value of omitted or set to 'default' its value is determined the value of
the BUILD option. the BUILD option.
DEBUG_RUNTIME_LIBS=0
DEBUG_RUNTIME_LIBS=1
(VC++ only.) If set to 1, msvcrtd.dll is used, if to 0, msvcrt.dll
is used. By default msvcrtd.dll is used only if the executable
contains debug info and msvcrt.dll if it doesn't. It is sometimes
desirable to build with debug info and still link against msvcrt.dll
(e.g. when you want to ship the app to customers and still have
usable .pdb files with debug information) and this setting makes it
possible.
TARGET_CPU=X64|IA64 TARGET_CPU=X64|IA64
(VC++ only.) Set this variable to build for x86_64 systems. If unset, x86 (VC++ only.) Set this variable to build for x86_64 systems. If unset, x86
build is performed. build is performed.
@@ -615,14 +425,18 @@ VENDOR=<your company name>
distribute wxWidgets DLLs with your application. Default value is 'custom'. distribute wxWidgets DLLs with your application. Default value is 'custom'.
This string is included as part of DLL name. wxWidgets DLLs contain compiler This string is included as part of DLL name. wxWidgets DLLs contain compiler
name, version information and vendor name in them. For example name, version information and vendor name in them. For example
wxmsw290_core_bcc_custom.dll is one of DLLs build using Borland C++ with wxmsw300_core_vc_custom.dll is one of DLLs build using Visual C++ with
default settings. If you set VENDOR=mycorp, the name will change to default settings. If you set VENDOR=mycorp, the name will change to
wxmsw290_core_bcc_mycorp.dll. wxmsw300_core_vc_mycorp.dll.
CFG=<configuration name> CFG=<configuration name>
Sets configuration name so that you can have multiple wxWidgets builds with Sets configuration name so that you can have multiple wxWidgets builds with
different setup.h settings coexisting in same tree. See "Object and library different setup.h settings coexisting in same tree. The value of
directories" below for more information. this option is appended to the build directories names. This is
useful for building the library in some non-default configuration,
e.g. you could change wxUSE_STL to 1 in include/wx/msw/setup.h and
then build with "CFG=-stl". Alternatively, you could build with e.g.
"RUNTIME_LIBS=static CFG=-mt" when using MSVC.
COMPILER_PREFIX=<string> COMPILER_PREFIX=<string>
If you build with multiple versions of the same compiler, you can put If you build with multiple versions of the same compiler, you can put
@@ -631,86 +445,14 @@ COMPILER_PREFIX=<string>
convenience variable, you can achieve the same effect (but different convenience variable, you can achieve the same effect (but different
directory names) with the CFG option. directory names) with the CFG option.
CFLAGS
CXXFLAGS
CPPFLAGS
LDFLAGS
Additional flags to be used with C compiler, C++ compiler, C
preprocessor (used for both C and C++ compilation) and linker,
respectively.
Compiler-Specific Options
----------------------------------------------------------------
* MinGW
If you are using gcc-2.95 instead of gcc3, you must set GCC_VERSION to
2.95. In build\msw\config.gcc, change
> GCC_VERSION = 3
to
> GCC_VERSION = 2.95
* Visual C++
DEBUG_RUNTIME_LIBS=0
DEBUG_RUNTIME_LIBS=1
If set to 1, msvcrtd.dll is used, if to 0, msvcrt.dll is used. By default
msvcrtd.dll is used only if the executable contains debug info and
msvcrt.dll if it doesn't. It is sometimes desirable to build with debug info
and still link against msvcrt.dll (e.g. when you want to ship the app to
customers and still have usable .pdb files with debug information) and this
setting makes it possible.
Fine-tuning the Compiler
----------------------------------------------------------------
All makefiles have variables that you can use to specify additional options
passed to the compiler or linker. You won't need this in most cases, but if you
do, simply add desired flags to CFLAGS (for C compiler), CXXFLAGS (for C++
compiler), CPPFLAGS (for both C and C++ compiler) and LDFLAGS (the linker).
Object and Library Directories
----------------------------------------------------------------
All object files produced during a library build are stored in a directory under
build\msw. Its name is derived from the build settings and CFG variable and from
the compiler name. Examples of directory names:
build\msw\bcc_msw SHARED=0
build\msw\bcc_mswdll SHARED=1
build\msw\bcc_mswunivd SHARED=0, WXUNIV=1, BUILD=debug
build\msw\vc_mswunivd ditto, with Visual C++
Libraries and DLLs are copied into a subdirectory of the lib directory with a
name derived from the compiler and a static/DLL setting and setup.h into a
directory with a name that contains other settings:
lib\bcc_msw
lib\bcc_lib\msw\wx\setup.h
lib\bcc_dll
lib\bcc_dll\msw\wx\setup.h
lib\bcc_lib
lib\bcc_lib\mswunivd\wx\setup.h
lib\vc_lib
lib\vc_lib\mswunivd\wx\setup.h
Each lib\ subdirectory has wx subdirectory with setup.h as seen above.
This file is copied there from include\wx\msw\setup.h (and if it doesn't exist,
from include\wx\msw\setup0.h) and this is the copy of setup.h that is used by
all samples and should be used by your apps as well. If you are doing changes
to setup.h, you should do them in this file, _not_ in include\wx\msw\setup.h.
If you set CFG to something, the value is appended to directory names. E.g.
for CFG=MyBuild, you'll have object files in
build\msw\bcc_mswMyBuild
build\msw\bcc_mswdllMyBuild
etc.
and libraries in
lib\bcc_libMyBuild
lib\bcc_dllMyBuild
etc.
By now it is clear what CFG is for: builds with different CFG settings don't
share any files and they use different setup.h files. For example, this allows
you to have two static debug builds, one with wxUSE_SOCKETS=0 and one with sockets
enabled (without CFG, both of them would be put into same directory and there
would be conflicts between the files).
Building Applications Using wxWidgets Building Applications Using wxWidgets
@@ -741,8 +483,8 @@ following to use wxWidgets:
* Add the list of libraries to link with to the linker input. The exact list * Add the list of libraries to link with to the linker input. The exact list
depends on which libraries you use and whether you built wxWidgets in depends on which libraries you use and whether you built wxWidgets in
monolithic or default multlib mode and basically should include all the monolithic or default multlib mode and basically should include all the
relevant libraries from the directory above, e.g. "wxmsw29ud_core.lib relevant libraries from the directory above, e.g. "wxmsw30ud_core.lib
wxbase29ud.lib wxtiffd.lib wxjpegd.lib wxpngd.lib wxzlibd.lib wxregexud.lib wxbase30ud.lib wxtiffd.lib wxjpegd.lib wxpngd.lib wxzlibd.lib wxregexud.lib
wxexpatd.lib" for a debug build of an application using the core library only wxexpatd.lib" for a debug build of an application using the core library only
(all wxWidgets applications use the base library). (all wxWidgets applications use the base library).