Very Computer

Thanks to all those who responded to my message. I'll be integrating
your comments into a new version (As well as finish the questions I
didn't do yet!)

OK. I didn't want to attack LD_LIBRARY_PATH _too_ hard, considering that
it's possible to make a case for using it. But I'll include that.

Quote:>>Q. What are the numerical extensions on shared objects for?

>A. These are version numbers.  When a new, not backwards compatible,
>version of a shared library is installed, the version number needs to
>be increased.

I intend to more verbosely explain when _not_ to change the version
number and how to use the ld -h option to take advantage of the
feature.

Also, it was suggested that I add a section on LD_PRELOAD and a few
other things.

BTW, someone pointed our that an object's run path and LD_RUN_PATH were
not the same thing. I'm going to need help on that one because I don't
know the difference. Thanks :-)

-Phil

Quote:

> BTW, someone pointed our that an object's run path and LD_RUN_PATH were
> not the same thing.

The run path is built into the binary.  The runtime linker uses
both the run path and the LD_LIBRARY_PATH environment variable
to search for libraries and shared objects.

To see what the run path for some binary is, use "dump -Lv":

        % dump -Lv /usr/openwin/bin/xterm
        :
        [12]    RPATH       /usr/openwin/lib
        :

There are two (equivalent) ways to set the run path:

- Compile with "-R".
- Set the LD_RUN_PATH environment variable before running the compiler.

In other words, LD_RUN_PATH and LD_LIBRARY_PATH do similar things, but
LD_RUN_PATH is consulted at compile time, and LD_LIBRARY_PATH at run
time.

Scott Seligman

The opinions expressed are my own.  Facts, though, are just facts.

Ah, that's quite nice! So if you have a big bulky scary system of
badly designed interdependant Makefiles that pass options to each
other in incomprehensible ways, you can still achieve the effect of
-R without needing to edit someone's Makefile (who didn't use -R!) :-)

-Phil

Except when you use gcc 2.7.0 where they decided to ignore LD_RUN_PATH
in the presence of -L options.

The solaris FAQ says:

6.8) After compiling X11R6 with gcc 2.7.0, X programs won't find their
libraries.

    Someone at GNU made a bad mistake by adding a the following
    misfeature to gcc 2.7.0: in the absence of -R options, specify
    a -R option for each -L option on the commandline.

    While this looks "neat" on the surface, this makes ld ignore
    LD_RUN_PATH, which is the mechanism used by R6 to set the RPATH.
    It also introduces a security hole, as it sets a relative RPATH for
    all X executables, including the set-uid ones.

    Workaround:

    remove the following bit from the gcc-lib/.../2.7.0/specs file:

        %{!static:%{!R*:%{L*:-R %*}}}

    then rebuild X.

    --- end of excerpt from the FAQ

Questions marked with a * or + have been changed or added since
the FAQ was last posted

The most recently posted version of the FAQ is available from
ftp.fwi.uva.nl in directory /pub/solaris

As opposed to, say, a _separate program_?

One of the many advantages of a separate program is that it may contain
code that more than one binary depends on. Thus, the code is only stored
once, in the separate program, and not in each individual binary. This
saves storage space on disk, especially when dealing with very common
code that nearly every program needs. But the benefits go farther than
the space savings: if the common code needs to be updated (for example,
a patch to fix a bug), this need only be done once, in the separate
program.

Another massive advantage is that separate programs are supported by
every UNIX system.

Quote:> A. It takes time for a program to load all of the shared library files it
>    needs and to link them to the main program and to other shared libraries
>    (called dynamic linking). The program will take longer to start up.

In contrast, modular programs are usually much faster than integrated
programs. They load from disk much more quickly, and they don't have to
do anything special before jumping into main(). Any commonly used
separate program (such as a compression program) is probably in memory
at any moment---the VM system worries about this---so it'll be there the
instant you execute it.

(Of course, some programs do so little useful computation, and so much
data movement, that modularity becomes an efficiency problem. For these
rare programs it helps if the OS allows fast message passing---i.e.,
program 1 asks the OS for a VM buffer, program 1 writes data into the
buffer, program 1 hands the buffer to program 2 without copying it.)

Quote:>    Finally, the system must be able to locate the require libraries
>    wherever they may be, which is, again, error prone. (See "What
>    is LD_LIBRARY_PATH?")

Of course, the system also has to be able to locate separate programs,
but PATH is much more familiar to users than LD_LIBRARY_PATH.

  [ Solaris now supports on-the-fly loading of shared libraries: ]

Quote:> To summarize, it is possible to select one or another
>    version of a set of alternative functions by loading one or
>    another shared library containing the same function, depending
>    on values found in a configuration file, or even depending on
>    user input.

Separate programs handle this trivially (and portably).

Quote:> Q. So should I use shared libraries?
> A. The real answer is of course, "it depends". But the easy answer is yes.
>    It seems to be the opinion of the community in general that the
>    advantages outweigh the disadvantages.

Of course. Shared libraries work wonders with hulking monoliths of code.
Most programs today are hulking monoliths of code. A kluge whose value
rests on the popularity of poor programming practice is a valuable kluge
indeed.

---Dan

Oh, come on.

Say there is a bug in 'printf()' which means that it does not perform as
expected in some obscure circumstance.  If the bug is fixed in a static library
all programs have to be recompiled.  If the bug is fixed in a dynamic library,
then all programs are immediately fixed.  If printf is in fact a fork to a
_separate program_ then sure, the bugs can be fixed as conveniently.  But the
overhead of having every system call fork a sub-process seems a little over the
top...

Jules

P.S.  If I have badly misunderstood, flame at will...

Quote:>---Dan

Sorry if I'm using the wrong terminology. According to your further
comments, I should have said ``the shared library bootstrapper in SunOS
4.x.''

But you seem to have missed my point, which is that bugs in such basic
code are exceedingly rare. This recompile-the-universe-every-few-weeks
scare scenario is a fantasy---despite the best efforts of thousands of
people to duplicate the same functions in one monolithic program after
another.

We've all worked on systems without shared libraries. On such systems,
monolithic program designs waste a lot of disk space. _That's_ the
reason shared libraries are useful in the real world.

Quote:> > Do you really worry about these possibilities? Does your system have so
> > many bugs at such a fundamental level?
> What about syslog()?

That's not fundamental; it's a perfect example of something that belongs
in a separate program. Ever hear of stderr? Ever try to run a test
version of telnetd without adding lots of bogus entries to your system
log files?

(28 May 1993, long before the latest bout of syslog() security holes:
``syslog is an unreliable, insecure, complex subsystem... One of the
beauties of UNIX is how you can write a very small program which _just
works_. You don't have to put all sorts of stuff at the beginning to
initialize windows and disks and check what sort of user you're talking
to, and you don't have to clean up at the end. You don't have to copy
code from one program to the next... Normal programs should reflect
errors in their exit codes. Depending on the situation they should _try_
to write errors to stderr, but they shouldn't get all uptight if that
fails. That's it. That's error handling in UNIX.'')

---Dan