Re: transitive shared library dependencies and installation

[Russ Allbery]

address@hidden writes:
> Bob Friesenhahn <address@hidden> writes:

>> That sounds like a great idea.  However, there is a problem that
>> linking on some systems does depend on already installed libraries (or
>> will end up using them) and so the libraries need to be installed and
>> linked in a particular order.

> Do you happen to know which systems these are?  Where are these
> constraints documented?

It's been a very long time since I've built shared libraries for any
platform other than Linux, but my distant recollection is that AIX and
HP-UX encoded the full path to the dynamic library against which a binary
was linked.  Therefore, if you built an executable against uninstalled
libraries, the executable would have a reference to the build directory,
hence the explicit relinking step after installation to pick up the new
paths.  I seem to recall that we caused an outage for campus AIX systems
because of this; I'm less sure about HP-UX.

I don't remember whether this also applied to interdependencies between
shared libraries (or if those platforms even supported encoding
dependencies in shared libraries; a lot of platforms didn't).  I vaguely
recall that mutually-dependent shared libraries were actually impossible
on at least some UNIX platforms, and thus not portable.

Note that AIX is very, very different than ELF-based UNIX systems (which
include Linux, Solaris, and I believe many of the BSDs) in how it handles
both shared libraries and system calls.  AIX shared libraries are quite
unusual.  I distantly recall that they're ar archives that contain a
special object file named shr5.o or something like that?

Both Tru64 and IRIX also had some odd linking behavior; I don't remember
if they would have had similar issues.

At the time, at Stanford we made the decision to build all binaries static
on all platforms other than Solaris and Linux because the shared library
behavior on other platforms was so odd and surprising that we weren't
confident we would get the details correct and avoid introducing weird
bugs.

It's of course an open question how much any given project cares about
supporting those UNIX variants these days.  Some of them are still sold
today, but the market share is quite small; others are varying degrees of
obsolete.  But that was the problem Libtool was originally written to
solve, and is why it does so many things that on Linux are weird and
unnecessary.

-- 
Russ Allbery (address@hidden)             <https://www.eyrie.org/~eagle/>