Re: Why relink the library during make install?

[Miles Bader]

Bruno Haible <address@hidden> writes:
>    configure --prefix=/A
>    make
>    make install prefix=/B
> 
> cannot expect that auxiliary files (in lib, share, doc, etc) will
> be found. The "make" process has no chance to put the pathnames
> /B/lib, /B/share etc. into the executables and libraries because it
> doesn't know about /B at that moment. In most cases, the installed
> package will not run.

Well, duh, that's how it's supposed to work!  People who do that know
what to expect (at least, I suppose, with every GNU package except yours).

> > Guess why in the world people using prefix=... in the 'make install'
> > at all?
> 
> a. Because they don't know about DESTDIR.

Or they don't use it because it's (1) not as powerful, and (2) not
supported as universally, as `make install prefix='.  The second point
is important to people who install lots of packages; they don't want to
worry about which package supports which installation methods, so they
use whatever is the most widely supported -- and that's the `prefix'
method, presumably because it's required by the GNU standards.

> On some operating systems, it cannot build the stuff completely until
> the shared libraries have been installed. This is why "make install"
> must relink.

On which systems?

If it's really impossible to make it work on certain systems, then I
suppose it's alright to say `make install prefix=...  isn't supported
correctly on systems X, Y, and Z' -- but that's no reason to not
support it correctly on others.  [And if the systems on which it doesn't
work are those over which we have some influence, then we should try to
fix them.]

DESTDIR isn't a sufficient solution for everybody, no matter how much
you like it (no, kludges involving temporary directories in /tmp and tar
are not good enough).

-Miles
-- 
Quidquid latine dictum sit, altum viditur.