After my how-to related to installing Suse linux on a HP pavilion laptop, I am willing to explain my findings when it comes to installing Python and GTK+.
The reason I went through this is because I needed to install a frontend for SDLmame called Wahcade.
Wahcade has a quite hefty list of requirements, so i consider it a good exercise upon which to base my how-to.
There are many, many things I've done during these nights of hard work, some pointless, some fruitful. It won't be easy to sum it up here in one shot, so, as with my tutorial for installing Suse, you will bear with me to delay reporting everything I need to tell you concerning these linux software and libraries installs.
Also, it seems that, depending upon the distro you're running and packages you choose at install time, some of the dependencies of Wahcade are already there. Fedora, in particular, seems to enhance the presence of "developer packages", so that setting up emulators and their frontends is a breeze (that's what a developer working on a popular linux emulator told me).
So please, take what you need, and leave the rest. Feel free to mention the obvious errors, omissions and so on. For people running KDE, it's supposed you installed the Gnome desktop. I'd say it might not be 100% mandatory, but it won't hurt either, except if you're really short on hdd space.
One more thing : Some portions of this article are copied & pasted text picked up from other's how-to I stumbled upon, while browsing. I know this is a questionable practice that might upset the authors, so I'll excuse myself.
Thing is, I simply can't "look back" to the point of finding the corresponding web page, asking permissions about these portions of text, crediting the authors and such. Such paragraphs will start with ", so feel free to email me if you think you're reading something you wrote.
Finally, there is a really central tool to all this, which you need to be familiar with : pkg-config. If you take the time to grab the tips & tricks of pkg-config, you might eventually appreciate to install more stuff from source, at least you will get a clearer picture of the meaning of packages scripts output. I feel this tool deserves more covering, so that's what we will try to do here.
Last but not least, some packages will be compiled from source, others will be installed/updated via Yast (simply use your own package config tool, in case you're running another distro). In the following list, PKG designates packages I compiled from source, and YPKG, packages those I downloaded via Yast.(to obtain them, read my other LQ article for the URLs of the corresponding repositories)
Enchant - get v1.4.2 from http://www.abisource.com/projects/enchant
dbus-devel (from DVD**)
del-tools & man*
* : May not be needed/related to GTK+/Python
** : When a newer version of the lib is likely to cause broken dependencies, I found that ticking the check box next to the version provided on the install DVD instead of the one from the online repository could solve the problem.
Bear in mind, the frame of my how-to is somehow broader that simply running wahcade. At worst, it could be considered as general guidelines on how to add developer packages to Suse or OpenSuse linux.
After a while, I wanted to show the world clearing dependencies was something a near-newbie on linux could do, if he proceeded in a logical manner. Speaking about Python, we will stick with v2.4, if that's Ok with you.
I'll tell you right away about some of the difficulties of these procedures.
First, the configure scripts might be broken. In fact, they may be broken or really broken. In the first case, you will need to copy by hand the files it couldn't cope with, in the second case, you will need to crosslink libraries***. (read below).
Second, Gnome desktop stores its precious libraries in /opt when most of the time, you do want them to gloriously figure in /usr. Yast won't let you change the install path, so you'll need to "fool your system" in a way, by compiling properly. Failing to do could get you straight to what we call the "dependencies hell". (A needs B, which needs C but C needs...A)
____END OF INTRO_______
Ok some definitions / clarifications first :
To run Wahcade you'll need:
- python >= 2.4
- pygtk2 >= 2.6
- chardet >= 1.0
(not required for python >= 2.5)
but also (optional)
*** Example of crosslinked libraries
I had to crosslink because the "very broken" png lib configure script would not permit the use of the correct file/link. Obviously, the following should be adjusted to your needs. Use at your own risk.
# ln -s /usr/lib/libpng12.so.0.29.0 /usr/lib/libpng12.so.0
0 means remove/delete
+ means copy/replace
Now let's see how the prefix scheme work (also called 'Alternate installation')
"The ``prefix scheme'' is useful when you wish to use one Python installation to perform the build/install (i.e., to run the setup script), but install modules into the third-party module directory of a different Python installation (or something that looks like a different Python installation). Usually the ``home scheme'' comes first. However, there are at least two known cases where the prefix scheme will be useful.
First, consider that many Linux distributions put Python in /usr, rather than the more traditional /usr/local. This is entirely appropriate, since in those cases Python is part of ``the system'' rather than a local add-on.
However, if you are installing Python modules from source, you probably want them to go in /usr/local/lib/python2.X rather than /usr/lib/python2.X. This can be done with
/usr/bin/python setup.py install --prefix=/usr/local"
In fact, as I said earlier, we *will* use the --prefix=/usr prefix extensively, as it seems the default configure scripts install stuff in --prefix=/usr/local
What is Cairo ?
Cairo is a vector graphics library with cross-device output support
What is Pango ?
Pango is a system for the layout and rendering of internationalized text
What about ldconfig ?
"ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so.
It checks the header and filenames of the libraries it encounters when determining which versions should have their links updated.
Also, ldconfig will attempt to deduce the type of ELF libs (ie. libc5 or libc6/glibc) based on what C libs, if any, the library was linked against. Therefore, when making dynamic libraries, it is wise to explicitly link against libc (use -lc).
Some existing libs do not contain enough information to allow the deduction of their type. Therefore, the /etc/ld.so.conf file format allows the specification of an expected type."
pkg-config : Better make it your friend !
translated from french :
"pkg-config is to libraries what apt-get or urpmi are to software. Unlike those two, pkg-config is the only one of his kind to be so polished and widely used. However, it has some major drawbacks.
First, it's not installed on every system. When your system doesn't include it, you should, as a developer, propose a viable solution.
As a user, if you're planning to compile a software which requires it, you're left with the sole solution of exporting LD_RUN_PATH=/usr/lib/installer.
In this case, another obvious drawback appears : very few, if any, libs will be declared in it.
For example, if glib was previously installed, you don't always have the definition files (.pc files) at your disposal to declare them to the pkg-config you just installed.
Something less obvious : If pkg-config in installed with the system, like with the new GNU/linux distros, you can be sure quite a few libs will be declared.
However, it will not be the case for everyone of of them, since some developers did not take the time to do so. As a libraries developer, try to include the definition files for pkg-config, if you can."
I believe pkg-config most important feature is to provide the precise version number of the already installed libs.
Here are all the commands I used to make sure I had the right versions :
pkg-config --modversion libpng
pkg-config --modversion glib-2.0
pkg-config --modversion gtk+-2.0
pkg-config --modversion glib
pkg-config --modversion gtk
pkg-config --modversion pango
pkg-config --modversion pixman-1
pkg-config --modversion cairo
pkg-config --modversion libdrm
pkg-config --modversion python
As you see, you must provide the correct name of the lib, for GTK+, typing gtk+ won't output anything.
I edited /etc/ld.so.conf this way :
Then simply typed
in a console with root privileges. Repeat if necessary (i.e. after "big" installs such as glib or GTK+...)
In case the config script is still unable to locate a lib or continues to display a wrong version number, try using the following :
export CPPFLAGS LDFLAGS PKG_CONFIG_PATH LD_RUN_PATH LD_LIBRARY_PATH PATH
(edit accordingly to your needs/paths)
gtk+, cairo, pygtk, pango, glitz, pixman & glib new versions are all installed in /usr
in some rare cases (freetype, libpng), I had to use the /usr/local path
- chardet is a Python program, install method is different :
python setup.py install
- pygtk should compile with all modules
- Libs version numbers can be misleading. I am used to version numbers using groups of 2 digits.
for example, is 2.8.12 greater than 2.12.6 ?
it's not, but I would have liked to see the first number written like that :
2.08.12 so no confusion would occur with 2.80.12.
Ok, I might be picky here, but version numbers are really something you should care about when updating, as config scripts often complains about such and such lib not being recent enough.
- Different versions of the same lib can coexist, provided they are installed in separate directories. For example Yast may be aware that Python 2.4 is install in /usr, but you might still want to install v2.5 in /usr/local for testing purposes. (make altinstall)
Usually, it's desirable to read at least the readme and install text files included (sometimes located in the /doc folder). Some libs such as Pango can be tricky to fix, if the prerequisites and/or the install path are wrong.
A few URLs :
In fact, if you're just realizing that Gnome is a fantastic development platform, and not only an alternate desktop to KDE, you might be interested in browsing (and downloading from) the following web sites :
General Gnome repository with fresh packages for each popular app
Base platform for desktop software on Linux and UNIX. The elements of this platform have become the backend for higher-level application-visible APIs such as Qt, GTK+, XUL, VCL, WINE, GNOME, and KDE.
Aimed at describing the most popular Gnome libs (developers might be interested in checking the jhbuild tool.
Noticing how wahcade manages to be a slick frontend for SDLmame, we may safely conclude that Glade seems to be a brilliant interface toolkit. As a matter of fact, it is also known to Windows users/students who install it via Cygwin.
That's it. If you enjoy chasing libs & their dependencies, you might try to setup pidgin, which is GAIM messenger official replacement.