How to install and find things in nonstandard locations?

["Thomas Mueller" <mueller6724%bellsouth.net@localhost>]

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.

Tom