Re: deploying libraries and executables from a staging area

[Ralf Wildenhues]

* Noel Yap wrote on Wed, Sep 20, 2006 at 11:43:58PM CEST:
> On 9/20/06, Ralf Wildenhues <address@hidden> wrote:
> 
> >To be able to say more (including whether it works portably ATM or not),
> >we need to know
> >- which libraries are involved (uninstalled ones, installed but at a
> >  different location in which they will ultimately appear, or installed
> >  ones at their final location),
> >- whether those libraries are static, shared, created with libtool or
> >  without (i.e., there is a *.la file or not),
> >- and the exact dependencies between them (including whether direct or
> >  not); best to show both the `libtool --mode=link' line for each of
> >  them and the respective output.
> >- and of course the same for the final binaries, too.
> 
> In the end, both /some/read-only/dir and /some/read-write/dir will be
> pretty much the same physical directory, but /some/read-only/dir will
> be read only.  In this scenario, I'm no longer sure what it means for
> a binary (both libraries and executables) to be 'installed' or not.

Definition 1:
A libtool library libfoo.la is called /installed/ if does not contain
the line `installed=no', otherwise it is called /uninstalled/.

Definition 2:
An installed libtool library is said to be /installed at its ultimate
position/ if it contains a line `libdir='LIBDIR'' and the name
  LIBDIR/libfoo.la
is a valid path to that very library.

Note 1:
A libtool library has to be installed at its ultimate position at the
time it is in regular use (on the $host, by programs that are executed
and that need (link or dlopen) it in some way).

Note 2:
A non-libtool library does not carry this extra information file, so we
only have a weaker notion we can use:

Definition 3:
A non-libtool library is said to be /at its ultimate position/ if it
appears at a path name from where it is regularly used.

Note 3:
For example, non-libtool libraries can have several valid path names,
whereas libtool libraries have one that is distinct.  For example, there
is (currently) no notion to say that a non-libtool library is
uninstalled or installed, so speaking of that makes not much sense.
(This is the reason why you cannot mix non-libtool and libtool libraries
in one package very well.)


Now, please answer the crucial missing questions:
1) Does the stuff (programs and libraries) you are building in your
package depend upon installed libraries that are not yet at their
ultimate position?
2) Do any libraries that you depend upon have themselves dependencies
that are not yet at their ultimate position?
3) For any library in (1) and (2): are they libtool libraries?  If yes,
please post the *.la file.  In any case (libtool libs or not), please
post `objdump -p libfoo.so' for them.

Now that you mentioned /some/read-only/dir and /some/read-write/dir, one
more question:
Can /some/read-write/dir be accessed in the form such as
  /some/prefix/some/read-only/dir

?  If yes, let's define /DESTDIR/ as `/some/prefix' and hence speak only
of DESTDIR from now on.


Just to give a couple more hints why the distinctions are important:
imagine that at the time you build your code (and install it into a
temporary, let's say DESTDIR, staging tree), there is both a set of
good third-party libraries (ones you wish to link against) below
$DESTDIR$prefix, and a set of bad third-party libraries below $prefix,
then it is important that you link against the good ones.

Later, at execution time, imagine that your programs and libraries, and
the set of good third-party libraries have been moved to their ultimate
position, imagine someone else builds a newer version of your package
and installs it below $DESTDIR$prefix.  Your programs and libraries
below $prefix should continue to work, however: they must not contain
run paths pointing to below $DESTDIR.

Since the respective old and new set of libraries may just be
incompatible for some reason (a newer version; or think about cross-
compiling for a different system), the path distinction is fundamentally
important for these cases.

Cheers,
Ralf