On Fri, Jan 03, 2003 at 03:10:44PM -0500, Sam Carleton wrote:
> On another OS a GPL software package, which uses the configure
> scritp, is having problems find all the libraries it needs.  I
> know that many folks would simply tell me to set the
> LD_LIBRARY_PATH.  But I also know, thanks to someone on this
> mailing list, that it is possible to link the path into the
> executable.  I learned this while trying to get my own source
> code compiled and running.

In this case, you want LDFLAGS=-L/whereve/those/libraries/are.
LD_LIBRARY_PATH is used by the runtime linker, LDFLAGS is used by ld
(see below). http://netbsd.org/Documentation/elf.html for information
on what this whole runtime linker stuff is about.

> I added this to my link command line: 
> 
> -Wl,-rpath -Wl,/usr/pkg/lib

Perhaps necessary, but not useful in solving your problem.

> My first question is derived from the -Wl flag, it is my
> understanding that this will passes commands onto the linker.
> This gives me the impression that gcc is NOT the linker.  What
> IS the linker?  Why is gcc launching the linker rather then
> directly running the linker?  Is the linker part of the gcc
> package or is the linker separate from the gcc package?  

The linker being used is GNU ld. It is part of the binutils package.

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.

So when you're using -Wl,-rpath -Wl,/usr/pkg/lib you're passing those
arguments to ld.

I'm no compiler author, but I would guess that these are separate
programs just because they're easier to maintain and debug if they're
all separate. Also, one may want to examine the output of just one step.
Say, for example, that you don't quite trust a macro that you wrote.
$ gcc -E test.c
That only runs the preprocessor on test.c, and you see the output of 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 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.

-- 
Soren Jacobsen