47b2f647b9
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@16139 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
365 lines
14 KiB
Plaintext
365 lines
14 KiB
Plaintext
Building wxPython on Unix or Unix-like Systems
|
|
----------------------------------------------
|
|
|
|
The basic steps for building wxPython for Unix or Unix-like systems
|
|
are:
|
|
|
|
1. Compile and/or install glib and gtk+
|
|
2. Compile and/or install wxGTK
|
|
3. Compile and install wxPython
|
|
|
|
We'll go into more detail of each of these steps below, but first a
|
|
few bits of background information on tools.
|
|
|
|
I use a tool called SWIG (http://www.swig.org) to help generate the
|
|
C++ sources used in the wxPython extension module. However you don't
|
|
need to have SWIG unless you want to modify the *.i files. I've made
|
|
several modifications to SWIG specific to wxPython's needs and so the
|
|
modified sources are included in the wx CVS at .../wxPython/wxSWIG.
|
|
If you need to modify the *.i files for wxPython then change to this
|
|
directory and run:
|
|
|
|
configure
|
|
make
|
|
|
|
(Do not run "make install" as wxswig is run in-place.) You'll then
|
|
need to change a flag in the setup.py script as described below so the
|
|
wxPython build process will use SWIG if needed.
|
|
|
|
I use the new Python Distutils tool to build wxPython. It is included
|
|
with Python 2.0, but if you want to use Python 1.5.2 or 1.6 then
|
|
you'll need to download and install Distutils 1.0 from
|
|
http://www.python.org/sigs/distutils-sig/
|
|
|
|
Okay, now on the the fun stuff...
|
|
|
|
|
|
1. Compile and/or install glib and gtk+
|
|
---------------------------------------
|
|
|
|
A. First of all, check and see if you've already got glib/gtk+ on your
|
|
system, all the Linux distributions I know of come with it, at
|
|
least as an option. Look for libglib.* and libgtk.* in your system's
|
|
standard library directories. You'll also need the headers and
|
|
config scripts in order to build things that use glib/gtk. Try
|
|
running gtk-config:
|
|
|
|
gtk-config --version
|
|
|
|
If you have version 1.2.5 or better then you're all set. You can
|
|
skip to step #2.
|
|
|
|
B. If your system has a binary package mechanism, (RPMs, debs,
|
|
whatever...) check and see if binaries for glib abd gtk+ are
|
|
available. Be sure to get the runtime library package as well as
|
|
the development package, if they are separate. Install them with
|
|
your package tool, and skip to step #2.
|
|
|
|
C. If all else fails, you can get the source code for glib and gtk+ at
|
|
http://www.gtk.org/. Fetch the latest of each in the 1.2.x
|
|
series. Compile and install each of them like this:
|
|
|
|
gzip -d [package].tar.gz | tar xvf -
|
|
cd [package]
|
|
./configure
|
|
make
|
|
make install
|
|
|
|
The last step will probably have to be done as root. Also, if your
|
|
system needs anything done to update the dynamic loader for shared
|
|
libraries, (such as running ldconfig on Linux) then do it after
|
|
each library is installed.
|
|
|
|
|
|
|
|
2. Compile and/or install wxGTK
|
|
-------------------------------
|
|
|
|
A. You can find the sources and RPMs for wxGTK at
|
|
http://wxwindows.org/, just follow the download links from the
|
|
nevigation panel. You can also check out a current snapshot of the
|
|
sources from the CVS server. (Some information about annonymous
|
|
CVS access is at http://wxwindows.org/cvs.htm.) The advantage of
|
|
using CVS is that you can easily update as soon as the developers
|
|
check in new sources or fixes. The advantage of using a released
|
|
version is that it usually has had more thorough testing done. You
|
|
can decide which method is best for you.
|
|
|
|
B. You'll usually want to use a version of wxGTK that has the same
|
|
version number as the wxPython sources you are using. (Another
|
|
advantage of using CVS is that you'll get both at the same time.)
|
|
|
|
C. If using the RPMs be sure to get both the wxGTK and wxGTK-devel
|
|
RPMs (at a minimum) and then install them as root.
|
|
|
|
rpm -Uhv wxGTK-2.2.2-0.i386.rpm wxGTK-devel-2.2.2-0.i386.rpm
|
|
|
|
D. If using the sources (either from the tarball or from CVS) then
|
|
configure it like this:
|
|
|
|
cd wxWindows # or whatever your top-level directory is called
|
|
mkdir build
|
|
cd build
|
|
../configure --with-gtk
|
|
|
|
There are gobs and gobs of options for the configure script, run
|
|
../configure --help to see them all. I'll describe some that I find
|
|
useful here.
|
|
|
|
If you have OpenGL or compatible libraries installed, then add the
|
|
--with-opengl flag.
|
|
|
|
If you are on Solaris and are using a recent version of GCC, then
|
|
you'll probably want to add the --enable-permissive flag so the
|
|
compiler won't barf on your broken X11 header files.
|
|
|
|
To make a debugging version of wxGTK, add the --enable-debug flag.
|
|
This sets the -g flag for the compiler and also activates some
|
|
special debugging code in wxWindows by defining the __WXDEBUG__
|
|
macro. You'll get some extra asserts, failure logging, etc.
|
|
|
|
To make a static library and not make a shared library, use the
|
|
--disable-shared and --enable-static flags.
|
|
|
|
NOTE: There is a potential type mismatch between Python and wxGTK.
|
|
This happens if Python defines some flags that turn on 64-bit file
|
|
offset support and wxGTK does not. This causes some basic types,
|
|
like off_t, to be typedef'd differently causing the C++ method
|
|
signatures to be incompatible and giving link errors at runtime.
|
|
If you get errors upon running a wxPython script that looks
|
|
something like this:
|
|
|
|
SeekI_13wxInputStream10wxSeekMode: referenced symbol not found
|
|
|
|
then that is probably the issue. This can be fixed in the current
|
|
code by predefining these flags before wxGTK's configure is run,
|
|
for example:
|
|
|
|
export CFLAGS="-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DHAVE_LARGEFILE_SUPPORT"
|
|
export CXXFLAGS=$CFLAGS
|
|
../configure --with-gtk --with-opengl --enable-debug
|
|
|
|
In the 2.3.3 final release there will be a real configure flag for
|
|
it, and it should be enabled by default. You will be able to use
|
|
--enable-largefile or --disable-largefile to control it. If you
|
|
still get this or a similar error with 2.3.3 then try disabling
|
|
largefile support in wxGTK.
|
|
|
|
E. Now just compile and install. You need to use GNU make, so if your
|
|
system has something else get GNU make and build and install it and
|
|
use it instead of your system's default make command.
|
|
|
|
make
|
|
make install
|
|
|
|
The last step will probably have to be done as root. Also, if your
|
|
system needs anything done to update the dynamic loader for shared
|
|
libraries, (such as running ldconfig on Linux) then do it now.
|
|
|
|
F. You can test your build by changing to one of the directories under
|
|
build/samples or build/demos, running make and then running the
|
|
executable that is built.
|
|
|
|
|
|
|
|
3. Compile and install wxPython
|
|
-------------------------------
|
|
|
|
A. You have the same options (and same advantages/disadvantages) for
|
|
getting the wxPython source, either a released snapshot or from
|
|
CVS. The released version file is named wxPython-[version].tar.gz
|
|
and is available at http://wxpython.org/download.php. If you want
|
|
to use CVS you'll find wxPython in the wxWindows CVS tree (see
|
|
above) in the wxWindows/wxPython directory.
|
|
|
|
B. As mentioned previouslly, wxPython is built with the standard
|
|
Python Distutils tool. If you are using Python 2.0 or later you
|
|
are all set, otherwise you need to download and install Distutils
|
|
1.0 from http://www.python.org/sigs/distutils-sig/.
|
|
|
|
On Unix systems Distutils figures out what commands and flags to
|
|
use for the compiler and linker by looking in the Makefile that was
|
|
used to build Python itself. Most of the time this works okay. If
|
|
it doesn't, there doesn't seem to be a way to override the values
|
|
that Distutils uses without hacking either Distutils itself, or
|
|
Python's Makefile. (Complain to the distutils-sig about this
|
|
please.) For example, on a Solaris system I had to edit
|
|
/usr/local/lib/python1.5/config/Makefile and replace
|
|
|
|
LDSHARED=ld -G
|
|
|
|
with
|
|
|
|
LDSHARED=gcc -G
|
|
|
|
This particular problem has been fixed in Python 1.6 and beyond,
|
|
but there may be similar issues on other platforms.
|
|
|
|
While we're on the subject of how Python was built... Since
|
|
wxPython is a C++ extension some platforms and/or compilers will
|
|
require that the Python executable was linked with the C++ linker
|
|
in order for everything to work correctly. If you build and
|
|
install Python yourself then this is easy to take care of,
|
|
otherwise you may have to mess with binary packages or bribe your
|
|
system administrator...
|
|
|
|
In my case on Solaris wxPython applications would core dump on
|
|
exit. The core file indicated that the fault happened after
|
|
_exit() was called and the run-time library was trying to execute
|
|
cleanup code. After relinking the Python executable the problem
|
|
went away. To build Python to link with the C++ linker do this:
|
|
|
|
cd Python-2.0 # wherever the root of the source tree is
|
|
rm python # in case it's still there from an old build
|
|
make LINKCC=g++ # or whatever your C++ command is
|
|
make install
|
|
|
|
I recently built Python 2.1.3 and Python 2.2.1 on Solaris and did
|
|
not have to resort to this workaround so apparently thigns are
|
|
getting better there. I will leave this note here though in case
|
|
there are similar issues elsewhere. However I did run into a
|
|
Python build issue that affects the wxPython build when attempting
|
|
to use SunCC instead of GNU gcc. See the note below titled
|
|
"Building with non-GNU compilers" if you are interested.
|
|
|
|
C. Change to the root wxPython directory and look at the setup.py
|
|
file. This is the script that configures and defines all the
|
|
information that Distutils needs to build wxPython. There are some
|
|
options near the begining of the script that you may want or need
|
|
to change based on your system and what options you have selected
|
|
up to this point, (sources from tar.gz or from CVS, etc.) You can
|
|
either change these flags directly in setup.py or supply them on
|
|
the command-line.
|
|
|
|
BUILD_GLCANVAS Set to zero if you don't want to build the
|
|
Open GL canvas extension module. If you don't
|
|
have OpenGL or compatible libraries then you'll
|
|
need to set this to zero.
|
|
|
|
BUILD_OGL Set to zero if you don't want to build the
|
|
Object Graphics Library extension module.
|
|
|
|
BUILD_STC Set to zero if you don't want to build the
|
|
wxStyledTextCtrl (the Scintilla wrapper)
|
|
extension module.
|
|
|
|
USE_SWIG If you have edited any of the *.i files you
|
|
will need to set this flag to non-zero so SWIG
|
|
will be executed to regenerate the wrapper C++
|
|
and shadow python files.
|
|
|
|
IN_CVS_TREE If you are using the CVS version of the
|
|
wxWindows and wxPython sources then you will
|
|
need to set this flag to non-zero. This is
|
|
needed because some source files from the
|
|
wxWindows tree are copied to be under the
|
|
wxPython tree in order to keep Distutils happy.
|
|
With this flag set then setup.py will
|
|
automatically keep these copied sources up to
|
|
date if the original version is ever updated.
|
|
If you are using the tar.gz version of the
|
|
Python sources then these copied sources are
|
|
already present in your source tree.
|
|
|
|
|
|
D. To build and install wxPython you simply need to execute the
|
|
setup.py script. If you have more than one version of Python
|
|
installed, be sure to execute setup.py with the version you want to
|
|
build wxPython for. Depending on the permissions on your
|
|
site-packages directory you may need to be root to run the install
|
|
command.
|
|
|
|
python setup.py build
|
|
python setup.py install
|
|
|
|
E. At this point you should be able to change into the wxPython/demo
|
|
directory and run the demo:
|
|
|
|
python demo.py
|
|
|
|
F. If you would like to make a test build that doesn't overwrite the
|
|
installed version of wxPython you can do so with this command
|
|
instead of the install command above:
|
|
|
|
python setup.py build_ext --inplace
|
|
|
|
This will build the wxPython package in the local wxPython
|
|
directory instead of installing it under your Python installation.
|
|
To run using this test version just add the base wxPython source
|
|
directory to the PYTHONPATH:
|
|
|
|
export PYTHONPATH=~/projects/wxWindows/wxPython
|
|
# or whatever is required for your shell
|
|
cd ~/projects/wxWindows/wxPython/demo
|
|
python demo.py
|
|
|
|
|
|
|
|
4. Building with non-GNU compilers
|
|
----------------------------------
|
|
|
|
As mentioned above Python's distutils uses whatever compiler Python
|
|
was compiled with to compile extension modules. It also appears that
|
|
distutils assumes that this compiler can compile C or C++ sources as
|
|
distutils makes no differentiation between the two. For builds using
|
|
GNU gcc and a few other compilers this is not an issue as they will
|
|
determine the type of source from the file extension. For SunCC (and
|
|
probably other compilers that came from cfront) it won't work as the C
|
|
compiler (cc) is totally separate from the C++ compiler (CC). This
|
|
causes distutils to attempt to compile the wxPython sources with the C
|
|
compiler, which won't work.
|
|
|
|
There may be better ways to get around this, but here is the
|
|
workaround I devised. I created a script that will execute either cc
|
|
or CC based on the file extension given to it. If Python uses this
|
|
script for its compiler then it will also be used by extensions built
|
|
with distutils and everybody will be more or less happy. Here is a
|
|
copy of the script I used. It was a fairly quick rush job so there
|
|
are probably issues with it but it worked for me.
|
|
|
|
#!/bin/bash
|
|
#--------------------------------------------------------------
|
|
# Try to determine type of file being compiled and then
|
|
# launch cc for C sources or CC for C++.
|
|
#
|
|
|
|
args=$@
|
|
is_C=
|
|
|
|
for arg in $args; do
|
|
|
|
# is the arg a file that exists?
|
|
if [ -e $arg ]; then
|
|
|
|
# does it end in ".c"?
|
|
if [ "${arg:${#arg}-2}" == ".c" ]; then
|
|
is_C=yes
|
|
fi
|
|
fi
|
|
done
|
|
|
|
# if the flag wasn't set then assume C++ and execute CC,
|
|
# otherwise execute cc.
|
|
if [ -z $is_C ]; then
|
|
exec CC -w $@
|
|
else
|
|
exec cc -w $@
|
|
fi
|
|
#--------------------------------------------------------------
|
|
|
|
I called it pycc, put it in ${prefix}/bin and set its execute
|
|
permission bit.
|
|
|
|
The next step is to configure and build Python such that it uses pycc
|
|
as it's compiler. You can do that by setting CC in your environment
|
|
before running configure, like this in bash:
|
|
|
|
export CC=pycc
|
|
configure
|
|
|
|
After making and installing Python with this configuration you should
|
|
be able to build wxPython as described in the steps above.
|
|
|
|
-----------------
|
|
robin@alldunn.com
|