[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile-2.0.11 installation on system with 2.0.5

From: Mark H Weaver
Subject: Re: guile-2.0.11 installation on system with 2.0.5
Date: Mon, 15 Sep 2014 10:15:10 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Neil Jerram <address@hidden> writes:

> On 2014-09-15 02:16, address@hidden wrote:
>> Federico Beffa <address@hidden> writes:
>>> I notice that there is an /etc/ file. Do I somehow need
>>> to update
>>> it?
>> Yes, you update it by running "ldconfig" as root.  This needs to be
>> done
>> when installing libraries outside of your package manager, not only for
>> Guile, but for essentially all packages containing libraries.
> I agree that this will allow /usr/local/bin/guile to load
> /usr/local/lib/libguile*.
> However, won't it also cause /usr/bin/guile (2.0.5) to load
> /usr/local/lib/libguile* (2.0.11) ?

True, but I don't see why anyone would want to run 2.0.5 anymore.  It
has lots of bugs and other problems that are fixed in 2.0.11, so that's
probably a good thing :)

> If not, what is the mechanism
> that tells /usr/bin/guile (2.0.5) to load /usr/lib/libguile* (2.0.5)
> instead of /usr/local/lib/libguile* (2.0.11) ?

This is not a guile-specific issue.  Any time you want to use two
different versions of the same shared library, you need to rely on some
other mechanism.

If you really want to preserve your ability to run the old buggy 2.0.5
libguile, then first of all you need to avoid installing 2.0.11 in a
directory that's in /etc/ (or /etc/, because even
if you avoid running "ldconfig" yourself, your package manager will run
it the next time you install a library package.  So, you'd have to
install 2.0.11 to a different prefix.

Then you need a way for your new PREFIX/guile to find its shared library
in a non-standard place, and for that you'd best use rpaths.  See
<>, but one way is to
make sure that LD_RUN_PATH is set to PREFIX/lib at the time that the
'guile' executable is linked.

Note that in GNU Guix <>, rpaths are always used
and this issue wouldn't have arisen.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]