Re: Guile 1.5.8 beta available for testing.

[Marius Vollmer]

Lynn Winebarger <address@hidden> writes:

>      The problem is for people who muddle with several development
> projects at once.  You might want to test development versions of
> both libfoo and the libfoo dependent appbar concurrently in
> /usr/local, but still want appbar to use the stable version of
> libfoo in /usr/lib because appbar has enough instability of its own.

The stable and unstable versions of libfoo should have different major
version numbers, so there should be no conflict.  You would need to
compile two versions of appbar, one that is linked against the stable
version of libfoo and one that is linked against the unstable one.

In my view, shared libraries are in a flat namespace.  Conceptually,
they are all in a single 'virtual' directory.  This single directory
is constructed from multiple 'physical' directories by merging them.
Ideally, this merging should happen in the filesystem, via somekind of
unionfs, say, but normally, it is just done with LD_LIBRARY_PATH or
something else and some rules that are not consistently followed by
the several library-accessing tools.

You might want to have different environments, each with it own way to
construct te single virtual library directory, but a program should
not try to put itself into its own environment.  That will lead to
chaos, in my opinion.

The best we can do, is to make the rules for constructing the library
directory consistent.  It is silly that ld finds its libraries in
different places as ld.so, for example.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405