This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
distributing gnu runtime libs
- From: Fox_Conor at emc dot com
- To: gcc-help at gcc dot gnu dot org
- Date: Wed, 15 Jan 2003 09:19:34 -0500
- Subject: distributing gnu runtime libs
Does anyone have opinions on strategies for distributing gnu runtime
libraries required by executables you built using gcc?
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.
(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.
(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.
Sorry for being long-winded! I know I'm certainly not the first person to
have come across this problem so I'd be most grateful to hear other peoples'
thoughts.