First off,  

There is a great deal of very useful info here, thanks!

On Fri, Jan 03, 2003 at 02:38:01PM -0800, Soren Jacobsen wrote:
> On Fri, Jan 03, 2003 at 03:10:44PM -0500, Sam Carleton wrote:
> 
> > I added this to my link command line: 
> > 
> > -Wl,-rpath -Wl,/usr/pkg/lib
> 
> Perhaps necessary, but not useful in solving your problem.

I don't understand why you say this.  In the little
application I wrote, it was not able to locate a library which
was located in /usr/pkg/lib at runtime.  After linking with
the above options, all worked fine.

The problem I am having on the other OS [Solaris 8(SPARC)] is
the same problem.  At run time, the location of the library is
unknown.
 
> 
> The gcc binary that you run is called a compiler driver. It calls other
> programs, and does not do any of the actual work itself. The steps are:
> preprocess (include other files, substitute macros, etc), generate code
> (assembly language for whatever arch), assemble the asm (create binary
> objects), and then link those objects. The programs that handle this
> are, respectively: cpp, cc1, as, and finally ld.
> 

Thanks!  This is VERY helpful!  I truly apprecaite it!

> 
> > I tried added the two -Wl, params to the LDFLAGS enviornment
> > variable before running configure and recieved the error that
> > the C compiler cannot create executables.
> 
> Try my above suggestion.

I assume that you are refering to adding the -L<lib path>, I
already have, sorry for not state so.

> > I am guess that this is not because the LDFLAGS is wrong, but
> > that the linker on this other UNIX OS is not the same one as
> > what is on NetBSD.  
> 
> ld itself doesn't recognize -Wl,-rpath -Wl,/usr/pkg/lib, it recognizes
> -rpath /usr/pkg/lib, and LDFLAGS are passed to ld, not gcc.

Ok, with this bit of info, I tried the following but with no
avail.  Any thoughts?

LDFLAGS = -L/usr/local/lib -L/usr/local/BerkeleyDB.3.3/lib -L/usr/local/ssl/lib -rpath /usr/local/BerkeleyDB.3.3/lib
export LDFLAGS

Sam