Following a quite heated discussion on #kde-devel about minimum versions of libraries required to build KDE trunk, I decided to describe how I install up-to-date libraries without messing with my distribution packages.
Installing a library by hand can usually be done in three places:
- Install in
/usr: this is a sure way to annoy the packaging system of your distribution… - Install in
/usr/local: this is the traditional way to install libraries by hand, but it is a bit difficult to uninstall things because files are scattered in the traditionallib,share,bin… folders. - Install in
/opt/library_name: this makes libraries easy to install and uninstall, but it needs a bit more work to make the library available to the rest of the system.
I personally like to use option #3. Installing a library this way requires specifying the prefix at configuration time. For libraries using autotools, this is done with ./configure --prefix=/opt/library_name. For libraries using CMake, use cmake -DCMAKE_INSTALL_PREFIX=/opt/library_name.
As I said, when you are done, you need to make the library available to the system. To do so, I use a simple shell script like this one:
pkgs="xine poppler qca exiv2"
for pkg in $pkgs ; do
prefix=/opt/$pkg
export PKG_CONFIG_PATH=$prefix/lib/pkgconfig:$PKG_CONFIG_PATH
export CMAKE_PREFIX_PATH=$prefix:$CMAKE_PREFIX_PATH
export PATH=$prefix/bin:$PATH
export LD_LIBRARY_PATH=$prefix/lib:$LD_LIBRARY_PATH
done
Replace the contente of the $pkgs variable with your package list and put this in a file sourced by your environment at startup. This can be your shell profile file or a file in the $HOME/.kde/env/ dir.
This script takes care of $PKG_CONFIG_PATH and $CMAKE_PREFIX_PATH, which should cover most library detection systems. Adding $prefix/bin to $PATH can also be useful if the library provide binaries. Adding libraries to $LD_LIBRARY_PATH is necessary to start programs using these libraries.
The nice thing about this setup is that it’s easy to enable/disable libraries. For example, after a distribution update you may find that you no longer need a hand-made version of a library: just remove its dir and its name from the shell script and you are done.
It is also possible to keep multiple versions of libraries installed on the same machine. You can then switch between them by adjusting the library name in the shell script or using symlinks.
Finally, if you replace /opt with say $HOME/opt, then you can easily install additional libraries without administrator privileges.
I hope this can help you to track KDE svn or other projects without too much pain.
Nice, I’ll try this #3 option. Thank you!
I remember using a program called gnu stow from my days with linux from scratch which does similar things. http://www.gnu.org/software/stow/
I prefer /usr because that is where Gentoo installs
Yep, that’s a nice way to break your system, especially when installing a newer version of some library, which is not compatbile with the system one (for example the core library of poppler, which does NOT guarantee any source- and binary- compatibility).
hehehe. But I’m sure if there is, it will be fixed
The discussion started with my questions about the kdegraphics cmake checks which were not accurate. I did not need to build anything from source in fact, my distro provides the required dependencies but they were not dealt with properly by cmake. The Exiv2 minimum version has been lowered and the libgomp-devel package check has been fixed. So the discussion should not have been heated as the questions were pertinent.
When KDE trunk requires a lib not yet provided by my distro, I put the source in KDE source dir, build it in KDE build dir and I install them in KDE install dir. Sort of way 3. but without root rights. It’s then easy to see what I have installed from source and to wipe it all to build clean and to install clean.
I upgrade my distro every 2 years or so, the rest of the time I only install security updates but no upgraded packages. No need to break a working kernel or XOrg, right? And I don’t have the time to always have my distro at the latest release.
> The Exiv2 minimum version has been lowered
That’s what I suggested you to try, but you refused to do it.
> No need to break a working kernel or XOrg, right?
Of course, we are not talking about such big components here. Building Exiv2 by hand does not take the same time as building the kernel or Xorg. If you use the method I present here, there is no way you can break your system.
I did not refuse to do it, but a CMake in a top module that I do not know so well needs some thinking before being modified: I did lower the version after I understood how kdegraphics works regarding Exiv2, just check my commit time. And Gilles fixed the libkraw cmake file.
The comment about the kernel upgrade was to justify that I keep a 1 or 2 years old distro overall, not to suggest it should be built by hand. It’s to explain why I do not have the very latest libs available.
> a CMake in a top module that I do not know so well needs some thinking before being modified.
I agree. But the very first thing you could have tried is to disable the version check and see if it builds. This would have brought important information to the discussion, much faster than Gilles or me installing the version of Exiv2 installed on your machine.
> The comment about the kernel upgrade was to justify that I keep a 1 or 2 years old distro overall, not to suggest it should be built by hand. It’s to explain why I do not have the very latest libs available.
If you keep a 1 or 2 years old distro (which I completly understand since upgrading/reinstalling distro can be quite time consuming) then you have to be ready to build libraries by hand as time goes on.
It would have been faster for you to install the latest Exiv2 than spend the time we actually spent on irc discussing the minimum version.
’stow’ is the answer!
I use it all the time, it’s soooo convenient! Every lib/app gets it’s own directory below /usr/local/stow/ (via build prefix) and then symlinked into /usr/local. When not needed anymore you can simply unsymlink and delete. When using you only need to care about /usr/local (add to KDEDIRS or *PATHs) …
I remember stumbling on stow some time ago but never tried it. I should give it a look.
stow +1