finding binaries/files/libraries not in Path -- specifically gcj

(1.) Is there a way to add EVERYTHING I have read/execute permission into my path? Sub-question, is this a bad idea?

...it's a bad idea for security reasons.

(2.) Does whereis only search my path? Is there some equivalent for finding files/directories I need without having to search the ENTIRE host and getting access-denied for every other directory?

You could use locate (or glocate available in findutils from OpenCSW) with the -r option which allows to use regular expressions: glocate -r /gcj$

(3.) Is there a way I can know for sure if a library/binary is definitely not available vs. just not in my path?

glocate can tell you that, assuming that gupdatedb has been recently run.

(4.) Is there a way to tell, specifically for gcc if gcj is available?

The best way of going about it is to scan the installed packages. The list of installed files is in /var/sadm/install/contents.

(5.) Can I compile gcj to my user directory without having to compile all of gcc with it?

Haven't tried, but you would still need to go through a lot of hassle. It's probably best to grab an already available gcj binary. If you have to compile it yourself, then it's best to use existing build descriptions, such as this one.

(6.) Is there a (universal) way, when building a binary, to flag the compile or make file to deal with any dependencies as it finds them rather than simply failing?

I assume you're thinking of something along the lines of Gentoo's emerge, which downloads and installs the dependent packages before it compiles the one you wanted. It's not easily done; especially if you compile everything as a regular user, because you need then to use a chroot environment. It's a good idea, but not trivial to do.

(7.) Does a typical user on a shared-host situation have the ability to use the OS package library to get packages at the user-level?

What do you mean by get packages? If what you want is to extract the contents of a .pkg file, you can use the pkgtrans command, like this: pkgtrans foo.pkg ./ all
However, there's also a possibility of doing something like pbuilder which creates a chroot environment, in which you do your compilation as well as package installations, all in the home directory.

Back to the gcj question, I think you need to specify the build time dependencies of your makefile and depend on a package that contains gcj, in a known path, and then you can use that path in your build description.

Generally, if you're in a shared hosting, compiling packages is going to be a pain, it's much better to find a system when you can install and remove packages, and write to /usr.

It's also a good idea to use some kind of a build framework, such as GAR, which does all the right things and removes lots of annoyances: it checks the build time dependencies, downloads tarballs, verified checksums, extracts, applies patches if any, configures, builds, installs, and makes a package, and you can specify everything in a single Makefile. Learning to use such a framework requires a bit of time, but if you tend to build packages yourself, the time spend on learning will pay off quickly.

1. Yes, it's a bad idea for security reasons. A malicious script or program, or a simple mistake could be a real problem.

2. whereis searches the obvious places like /bin, /usr/bin and others. See the man page FILES section

You can use locate if it's available or find otherwise:

locate gcj

or

find / -name gcj

1: Nobody does that -> bad idea.

2 + 3: The sure way is:

pkginfo | grep -i gcj         # (Solaris specific)
find / -name gcj 2>/dev/null

4: Don't know.

5: Probably, and it is obviously a lot of manual work.

6: No. In Makefile, you can just append to PATH any directories that usually hold gcj (your educated guess). This will not hurt anyone.

7: No, it is up to admin to install a package. But you don't need to be an admin to extract the files contained in the package to your home directory:

pkgtrans my-gcj.pkg .     # (Solaris specific) converts package to a "filesystem format package" (i.e. directory tree)

The software will rarely be usable after such substraction (bad ownership, bad path, bad library paths, bad config file paths, no installation script executed, no pre-requisites checked, ...). Such operation is also possible not only on Solaris, but on most other Unix/Linux flavors - using their packaging tools.