SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Let's say I have a package that I compile and install, but later I get an updated version and compile that one too.
Of course, both versions use the same name for the executable, and I, well, I want to use both.
In fact, soon I will want to compile a third version of the program, and want the invoke the program in all three versions.
Again, the executable will always have the same name.
So what's the most elegant way of doing this?
Putting the three executables in the same directory with the same name? >> Nope, very unwise.
Put them in a separate directory and write a special alias for them where the full directory path appears? >> Sounds good.
Rename the executable, and put them the same directory? >> Possible, but not preferred because other systems users won't know what they are, might get confused.
Of course, that's the easy scenario, when the version use the same version of libraries. If they use different versions, well, then, the call to the executable needs to link those in.
All in all, if I want to have so many version of the saem program, and not disturb anybody else, it's porbably better that I write a little one or two bash script and keep them in a private directory of mine, and include the private directory in my $PATH.
How does that all sound? Anybody have a different way of doing this?
By way of illustration suppose I am thinking of Firefox, I'd like to use v1.5, v2.0 and also install the alpha or beta v3.0 three same-named executables, prob using different version of libraries. THe aboe is how I'd do it. Fair enough?
FF is an easy example since it's selfcontained: all the scripts, executables and libraries it comes with all reside in one directory. Would be easy to symlink them to /usr/local/firefox-1, /usr/local/firefox-2, etc and one "firefox" link to the "default" one. If it OTOH is an application that uses different library versions you could install the version-specific libraries in say /usr/local/lib/appname-version and export LD_LIBRARY_PATH in a startup function or script.
The best way to handle having various versions is to build and install each one into it's own directory and then use a small wrapper script for each one. The wrappers can be placed in your normal path. Simply creating links to the programs won't always work and using a wrapper will let you set the PATH and LD_LIBRARY_PATH if needed, or cd into the directory where the program is located and start it from there(if that's what the program needs)
The preferred method is to use '/lib/ld-linux.so.2' to invoke your program because the alterred LD_LIBRARY_PATH won't be passed on to spawned processes. Changing LD_LIBRARY_PATH doesn't typically cause any problems but if you are creating a wrapper script anyway, you might as well "do it right".
I've got FF2, FF3, Xulrunner, Prism, Flock, Opera, Amaya, and Webkit - all of them installed in "/opt/browsername-version-number" including a source tree of recent Firefox 2 and Webkit plus Flash and Java.
Depending on what exactly I need to start, I've got a handful of little wrappers in ~/bin/ - firefox2.sh, firefox3.sh and so on as startup scripts.
Enviroment variables like PKG_CONFIG_PATH or LD_LIBRARY_PATH are set per project depending on what I need to set to whatever browser environment.
Konquerer and Epiphany reside within my KDE-trees and within my Gnome-tree - all three also installed in /opt (opt/kde3, opt/kde4, /opt/garnome).
My glib/gtk/pango/freetype-stuff within /usr/ in the main system is usally very recent and patched for better subpixel/bytecode stuff but entirely gnome-free and untouched otherwise.
So, if I need most recent Gnome libs and something from Webkit libraries - to compile some browser with Webkit instead of Gecko, I just set the environment accordingly to my /opt-realm and install it somewhere appropriate.