up vote 1 down vote favorite
share [g+] share [fb]

Yesterday I downloaded an app called mvPod, which came in a tarball.

I was under the impression that if I have any programs not installed by the package manager, they belong in /usr/local rather than /usr. But if I put the executable in /usr/local/bin, and the jar files into /usr/local/lib, I get runtime errors about being unable to load the Java classes. So I resorted to putting things in /usr/bin and /usr/lib and it worked fine.

Is this something that can only be corrected by compiling differently, or am I missing an installation step?

I'm running Ubuntu Karmic.

link|improve this question
feedback

2 Answers

up vote 4 down vote accepted

The problem with putting hand installs into /usr rather than /usr/local is that

  • you won't know immediately how something was installed which makes fixing problems harder later on
  • some package could clobber part of your installation or vice versa (just part is much worse than all, trust me)

The reason a /usr/local installation wasn't working is almost certainly associated with some search path or another. These can be configured for each program doing the searching or stored in environment variables, or often make use of both methods. For all types of programs, you'll want to be sure that the PATH, LD_LIBRARY_PATH, and MAN_PATH environment variables are updated. Java may involve a CLASS_PATH or something similar. Maybe you'll get a more specific answer here, or as a last resort there is always the documentation.

Another thing: some unixs expect local installs in /opt rather than /usr/local. It is always worth checking the local convention on that.

link|improve this answer
+1 for environment setup. everything will just work if he sets his paths properly. – Justin Smith Feb 15 '10 at 3:20
Thanks for the info! This sort of thing was my first thought (before posting this question) but I was a bit turned off that googling "LD_LIBRARY_PATH" mostly finds people saying that it's a hack. It seems it would be more correct to fix this at make time, but it's annoying then that the distributed binaries were made with the "wrong" paths... – Owen Feb 19 '10 at 18:43
@Owen: the dynamic loader (ldd) has a config file (ld.so.conf usually in the /etc hierarchy, and managed with ldconfig) to tell it where to look on a global basis: If you have root access you can fix that instead of fooling around with your personal PATHs. – dmckee Feb 19 '10 at 20:51
feedback
up vote 1 down vote

You can use the --prefix option with configure, make or both.

./configure --prefix=/usr

or

make prefix=/usr install

This will install in /usr instead of the default /usr/local.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.