[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
How to install and find things in nonstandard locations?
I asked some time ago about the possibility of building experimental versions
of packages, such as Seamonkey 2.1 alpha or beta, and installing to a
nonstandard location such as /usr/local2 or /usr/testing. Then I could run
such a package by spawning a subshell with /usr/local2/bin and /usr/local2/sbin
at the start of the PATH, and I would still have access to the established base
system and packages without installing everything in duplicate. Then after
exiting the spawned subshell, I would still be able to use the installed
release version (Seamonkey-2.0.11 or whatever).
Question is how to install to such a directory prefix, and subsequently when I
need to subsequently link to these packages' libs and includes, how to make the
compiler and linker, and programs run therefrom, such as sed and grep, find
these libs and includes.
This problem arises with Slackware Linux, though I am not using pkgsrc in this
case, or not yet, and spawned programs such as sed and grep can't find things
in /usr/local/lib or /usr/local/include even though I add these directories to
the lib and include paths. In this case, I can't see how gcc in Slackware
would find things in /usr/pkg either, and would have problems using pkgsrc if I
tried that. Perhaps libtool is at fault? One possible workaround, albeit
inelegant, is to put a symbolic link in /usr/lib to anything not found because
it was in /usr/local/lib; I actually did that in some cases. I'm afraid to
remove the libtool package, though I see there is no libtool in NetBSD base
system, and NetBSD does not suffer from libtool's absence. I have compiled and
recompiled the kernel many times.
Slackware package manager is good at installing, removing and upgrading binary
packages but knows nothing about dependencies, or about building from source.
Seeing what NetBSD pkgsrc, FreeBSD ports, and some other Linux distributions do
makes me realize how backward Slackware is.
One thing I could do is build the latest version of libtool (2.4) from source,
make a package ready to install, remove the old libtool package (1.5.26), and
see if the packages I'm trying to build will build without libtool. Then if
libtool is needed, I can install the new version and see if it works. I could
also download and build the new gcc suite (4.5.2). Or I could test by booting
System Rescue CD (I have v1.5.0), which I believe has the gcc tools, and see if
that will build my packages: see if the fault lies within Slackware.
Main Index |
Thread Index |