[Top][All Lists]

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

Re: Problem installing the intended version

From: Thomas Morley
Subject: Re: Problem installing the intended version
Date: Sat, 10 Aug 2019 20:39:28 +0200

Hi Mark,

Am Fr., 9. Aug. 2019 um 19:51 Uhr schrieb Mark H Weaver <address@hidden>:
> Hi Thomas,
> Thomas Morley <address@hidden> writes:
> > recently I tested building LilyPond against guile-2.2.6 without
> > success[*] and tried to investigate whether the problem is on the
> > guile-side or at LilyPond (there are some patches which may or may not
> > cause the problem).
> >
> > Though I stumbled across a problem which may be caused by guile or my
> > naivity ...
> >
> > I had built guile-2.2.6 from the git repository and installed it via
> > `sudo make installĀ“
> > Then I did (in/for a fresh repo):
> >
> >   git clone git:// ~/guile-2.2.4
> >   cd guile-2.2.4/
> >   git checkout v2.2.4
> >   git checkout -b guile-2.2.4
> >   sh
> >   ./configure
> >   make
> >
> > All successfull, then some tests:
> >
> >   ./meta/guile --version
> >   -->  guile (GNU Guile) 2.2.4 [...]
> >   ./meta/guile-config --version
> >   --> guile-config - Guile version 2.2.4
> >
> > Then installed it systemwide
> >
> >   sudo make install
> >
> > And made some testings:
> >
> >   which guile
> >   --> /usr/local/bin/guile
> >   /usr/local/bin/guile --version
> >   --> guile (GNU Guile)
> >
> > Obviously 2.2.4 was _not_ installed but 2.2.6 from another repo.
> >
> > What am I missing?
> What's happening here is that although the executable
> /usr/local/bin/guile is from 2.2.4, it is being dynamically linked to
> the newer from 2.2.6 that you installed earlier.
> The libguile from guile 2.2.4 is
> This happens because you never uninstalled the newer
>, and the library versioning information that we
> assigned indicates that is a drop-in replacement
> for  In other words, to our knowledge, any
> executable linked with should also work properly
> when linked with  That's because we added new
> interfaces but did not change or remove any existing interfaces.

many thanks for your analysis.

I am used to switch guile versions between
guile-1.8.8 (still LilyPond's default)
guile-2.0.14 (previous guile-stable, but I didn't use it for some
time, newer versions are superior)
guile-2.2.x (current stable)
guile-2.9.x (prereleases for upcoming stable-3.0)

In the past I checked the last two only upstream, right now it's the
first time I tried to downgrade for another micro-version.

In the light of your explanations I think the current problem only
occurs for _equal_ major/minor with _different_ micro versions.

> If you want to prevent from guile 2.2.6 from being
> used, you should delete it, and then run 'ldconfig' as root to update
> the links and caches.  Hopefully after that, and
> should be symlinks to
> A more thorough approach, to make sure that no components of 2.2.6 are
> being used, would be to run "make uninstall" from the Guile 2.2.6 build
> directory (if you still have it), then rerun "make install" from the
> Guile 2.2.4 build directory,

Doing "make uninstall" before installing a different micro-version
solves the problem.

> and finally "ldconfig" as root.

Doing so I get:
/sbin/ldconfig.real: /usr/local/lib/ is
not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig.real: /usr/local/lib/ is
not an ELF file - it has the wrong magic bytes at the start.

And I've got even more notifications of this kind before I started to
do the "make uninstall"-thingy.
Is this expected?
See also
which is the most recent post about it, as far as I know.

Thanks a lot again, right now I'm testing LilyPond against guile-2.2.4.
If I remember correctly this should work, better to verify again,
though. And then I can investigate further on both sides.


reply via email to

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