I would consider the above a "typical user's build" in that it is as optimized
and as portable as is safely possible. Lots of libs are built-in. It is not set for debugging, yet
the "--enable-debug_flag" is there for python to use to send error messages without just crashing.
ODBC gave me fits in the past, due to the unicode implimentation. I got a work-around going once --
but it was not well-tested and so I avoid it now. Slackware is using UCS2, while several distros have already
gone with UCS4 for Python unicode (16 and 32 byte.) I'm not sure if wx has trouble due to such "growing pains",
but UCS4 will in all likelyhood be the norm soon. But not just yet. I'm just as sure that ODBC in the next WX release
will be easier to compile. Anyway -- if all goes well, you should see something like the following after the configure runs:
Configured wxWidgets 2.6.1 for `i686-pc-linux-gnu'
Which GUI toolkit should wxWidgets use? GTK+ 2
Should wxWidgets be compiled into single library? no
Should wxWidgets be compiled in debug mode? no
Should wxWidgets be linked as a shared library? yes
Should wxWidgets be compiled in Unicode mode? yes
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.2 no
wxWidgets 2.4 yes
Which libraries should wxWidgets use?
jpeg builtin
png builtin
regex builtin
tiff builtin
zlib builtin
odbc no
expat builtin
libmspack no
sdl yes
gnomeprint no
As you can see, I do not use Gnome (hence Gnomeprint is disabled.)
If configuration went well for you, then we have the one tricky part left for those of us who are
just doing a straight install: we need to run make from the present directory, but also run make for
a few other controls separately. But go ahead and type
make
That gives me about an hour to kill. My last build was on a P4 2Ghz that runs at an average clip.
Obviously your time will vary. When that is done we will install the "base" and then build the other controls.
|
When your "make" completes, take a moment to enjoy that feeling. That part was the most likely for
something to go wrong -- at least the way I install wx. More on that later. We
will now employ that handy tool "checkinstall" to get a package of the wxGTK base.
|
Instead of typing "install", simply type:
checkinstall
Checkinstall asks a few questions as it proceeds, but following the prompts is rather intuitive. When it has completed
the wxGTK base will be installed and a package built in your present directory. Remember where that is, as we will be using it later.
One last tip for the initial build, after checkinstall runs and both installs and creates your package -- type:
ldconfig
The above will ensure that your newly installed library files will be available to the system.
That is needed for the next section, those extra widgets I mentioned earlier. This should NOT be necessary,
because we are installing the libs into the standard location. But why take a chance?
The next part is where things may seem a bit tedious, but I install in this manner to avoid any
linking errors that can be tough to figure out. What we will be doing is installing the extra widgets
separately, with the libraries already installed for wx. If you did not do it this way you would have
to add the temporary location of the libraries to your LD_LIBRARY_PATH, and also worry about getting
hard-coded paths in wx that would, upon full install, be in error. Some folks set the -rpath flag to
avoid that possibility, but I prefer the method I describe below.
|
Installing the extra widgets
Once the "base" install of wxGTK is
installed we have to cd to a few lower directories to run make on a few things. They are
stc, gizmos, animate and I also did svg. Below is a composite image of the directory
structure and at the bottom are the directories I listed above.
Being in the top directory after running "make", you have to cd to the dirs we are after
one at a time. In each you will run "make" and checkinstall.
cd contrib/animate/src
make
checkinstall
Repeat the above for each of the 4 directories I listed above.
Remember what each one is named as you run checkinstall. Now here is the tedious part --
What we are going to do is
pull the base and the other 4 packages aside, then uninstall all of them from your system. I use xpkgtool
on Slackware, but you can use any tool you are familiar with. Then expand the five packages and
combine the four extra widgets with the base package.
This just means to add the lib and include files into the wxGTK package from the others, and append the
linking routines that are in the install/install.sh script on Slackware. When they are all combined into one,
you then rebuild the package. CD to the directory and run makepkg packagename, or repack
as the package type you are using.
And finally, reinstall the combined package. You can run ldconfig again, just to be sure . . .
Congratulations, wxGTK-2.6.1.0 is installed.
Now you have to install the Python bindings. This part is easy.
Installing wxPython
cd to the wxPython directory, then run the following command:
checkinstall python setup.py UNICODE=1 EP_ADD_OPTS=1 install
NOTE: latest (2.6.2.1) version I compiled for Slackware-curent (2/27/06) errored out compiling glcanvas.
If you need (and you also have the problem) -- you will have to find a work-around. I was not using glcanvas, so I
set the build command not to use it, as shown below.
checkinstall python setup.py UNICODE=1 EP_ADD_OPTS=1 BUILD_GLCANVAS=0 install
And, believe it or not, you are done. You can then store the package you just made (should
have been named, on Slackware, wxPython-2.6.1.0-i386-1.tgz) along with the other combined wxGTK package
you made. Keep those two packages safe, and if you need to install wxPython on a similar/replacement machine,
you can use them instead of going through all this again : )
This may seem like a convoluted manner in which to install wxGTK and wxPython, but I avoid linking errors during
compilation, I don't have to add paths to the system and I don't have to alter the way wx functions (ie -rpath.) It is also much
easier to pin down a problem if something goes wrong during the build.
I have seen scripts to do this, but they are usually distro-specific. The method described here can be adapted to
most anything. Of course, if you have a package manager you trust, use that . . . but personally I do not trust automated package management.
| |
I use Slackware. I configure things myself -- then I Slack.
|
|
|
Pages created and served by Linux
from source code
