[CALUG] gcc question

[Dave Dodge]

On Tue, Jan 17, 2006 at 07:12:14AM -0500, Jason C. Miller wrote:
> I have some code that dynamically links to various libraries around
> the system.  BTW, this is a Solaris 8 box and static linking isn't
> an option.

Is the lack of static linking an intentional decision on your part, or
just the result of the system?  I'm asking because the simplest
solution is to statically link the libraries you're having an issue
with, while leaving the rest dynamic.  To do this you will need static
versions of those particular libraries (filenames ending in .a).  The
most portable way to tell the compiler to link a specific library
statically is to just put the .a file on the command line in place of
the -l option, like this:

  gcc -I<whatever> /path/to/libWhatever.a code.c -o code

Assuming you do _not_ have static versions of those libraries...

> I've been told that I can do this.  However, I really don't know the
> right buzzwords to google for without returning a million irrelevant
> results.  Is this a function of gcc or ld?  And also, which
> argument(s) should I look at?

The linker can probably set the library search path in the executable.
It may do this automatically from the -L options, or it might require
you to pass an option through gcc to the linker.  This might be called
"-R", or "-rpath", or something similar.  Check the "ld" manpage.  gcc
on Solaris probably uses the Solaris linker instead of the GNU linker;
beware that those two linkers are very different and sometimes use the
same command-line options to mean completely different things.

One way you can pass options to the linker from gcc is to use -Wl with
commas.  For example to tell the linker "-R /some/path", you would
tell gcc "-Wl,-R,/some/path".

> What I want to do is to copy all of those various libraries into the
> directory where the new executable will reside and link to those.
> Basically, I just want to be able to package up the directory and
> send it off to anybody who wants to use it without requiring them to
> do any funky post install.

One problem is that when you "send it off", you don't necessarily
control where the files are unpacked on the other user's system.  So
if you have a hardcoded library path in the executable, it might break
if they unpack to some other location.  If you use a relative path
such as "./", it might break if they invoke the program without being
in the current directory.

A typical solution to this is to use a wrapper script to run the
program.  You'd rename your program to something like "code.bin", and
then write a "code" shell script that does things like:

  - tries to use $0 to figure out where the directory is located on
    the system.

  - sets the LD_LIBRARY_PATH environment variable so that your library
    directory is at the front.  On Solaris (and Linux), this
    environment variable is one way of influencing the library search
    algorithm.

  - executes the code.bin program, passing along the command-line
    arguments (usually with "$@").

Sometimes there is also an "install" script of some sort, which the
user is required to run ahead of time.  This would take care of the
first step of finding out where the program is installed, and then
stub the correct paths into the wrapper script.

See Firefox, Netscape, Mozilla, or (I think) Sun's "java" for examples
of how a wrapper script might be used.

                                                  -Dave Dodge