distributing gnu runtime libs

[Peter Kurpis]

>  Wed Jan 15 04:20:27 2003

> Does anyone have opinions on strategies for distributing gnu runtime
> libraries required by executables you built using gcc?  

Opinions follow.  :-)

> For example  my Solaris executable requires libstdc++.so.x and libgcc_s.so.y
> .  In general I have three choices:
> (1) When installing my app, copy each library file into the system's library
> directory (/usr/lib on Solaris).  The problem with this is that some other
> file of the same name may already exist in this directory e.g. a version of
> libstdc++.so.x that was built using a special gcc build configuration.  Some
> other application may be dependent on some aspect of this unique
> libstdc++.so.x version so I don't want to overwrite it with my version --
> however now I'm in trouble because my executable may depend on some unique
> aspect of my libstdc++.so.x.  Perhaps this is unlikely in practice but it
> could happen.

Sounds like you're distributing binaries.  Why not distribute source and
let the user build your application.  That way, you can specify prerequisites
in the build instructions.  (This seems to be the usual way to distribute
UN*X applications, and overcome the problems you are trying to address, 
plus give the user some flexibility.)

On the other hand, if you need to distribute binaries, you are likely
targeting a specific system.  For instance, linux has a mechanism (called
RPM, I think), which probably handles the problems you are trying to 
address.  In other words, for a given OS, I think there is some sort
of protocol to do what you want (e.g. RPMs in linux, packages in solaris,
ports in freebsd).

Perhaps you could take a look at OS websites, to get ideas about how
applications like yours are usually distributed.

I think "rolling your own" installation mechanism would be a waste of
your time (i.e. reinventing the wheel) and introducing something non-
standard where adequate "standards" probably exist.

> (2) Build the executable using a custom-built gcc version that has
> associated "special" versions of each shared library.  This will cause the
> executable to bind to the uniquely-named special library at runtime.  For
> example I could build a gcc that is configured to create executables that
> bind to libfoostdc++.so.x.  Then when I install my executable I can also
> install libfoostdc++.so.x into /usr/lib with impunity.  The drawbacks are
> (a) I have extra work in configuring the gcc build correctly  (b) Its
> space-inefficient and kind of inelegant -- if everyone did this, there could
> be dozens of copies of essentially the same library on each system, each
> with their own oddball name.

Yikes.  I think the reasons you stated are enough to cross this option
off the list.

> (3) Retain the normal names for the libraries but don't copy them into
> /usr/lib.  Instead at install time extend the system's library search path
> (e.g. set LD_LIBRARY_PATH in Solaris and most other Unixes) so that each
> library can be found.  This is kind of brittle because people tend to mess
> with LD_LIBRARY_PATH path a lot.  Also like solution (2) it results in
> multiple copies of essentially the same library, if many gcc-built apps get
> installed on the machine.

LD_LIBRARY_PATH is bad for a number of reasons, see

	http://www.visi.com/~barr/ldpath.html

Plus, cluttering a number of directories with different libraries
creates a mess.  UN*X traditionally allows (expects) some user configuration
of installation.  This is for a number of reasons, but one major one for
you is that you cannot reasonably predict how to "automate" an installation.
In other words, if you choose a library location, and automatically set
LD_LIBRARY_PATH, you've introduced a host of problems.  Not only brittleness
in finding the library, but how about the setup of LD_LIBRARY_PATH in other
accounts that want to use your software?  And so on...  all decisions
better left to the installer.