Problem installing the intended version

Problem installing the intended version

[Thomas Morley]

Hi,

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://git.sv.gnu.org/guile.git ~/guile-2.2.4
  cd guile-2.2.4/
  git checkout v2.2.4
  git checkout -b guile-2.2.4
  sh autogen.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) 2.2.6.1-a69b5

Obviously 2.2.4 was _not_ installed but 2.2.6 from another repo.

What am I missing?


Thanks,
  Harm

[*] To be more exact: `make´ succeeded for LilyPond, but `make
test-baseline´ failed.

Re: Problem installing the intended version

[Thomas Morley]

Am Do., 8. Aug. 2019 um 22:19 Uhr schrieb Thomas Morley
<thomasmorley65@gmail.com>:
>
> Hi,
>
> 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://git.sv.gnu.org/guile.git ~/guile-2.2.4
>   cd guile-2.2.4/
>   git checkout v2.2.4
>   git checkout -b guile-2.2.4
>   sh autogen.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) 2.2.6.1-a69b5

Forgot to add:
  which guile-config
  --> /usr/local/bin/guile-config
  /usr/local/bin/guile-config --version
  --> guile-config - Guile version 2.2.4
>
> Obviously 2.2.4 was _not_ installed but 2.2.6 from another repo.
>
> What am I missing?
>
>
> Thanks,
>   Harm
>
> [*] To be more exact: `make´ succeeded for LilyPond, but `make
> test-baseline´ failed.

Re: Problem installing the intended version

[Mark H Weaver]

Hi Thomas,

Thomas Morley <thomasmorley65@gmail.com> 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://git.sv.gnu.org/guile.git ~/guile-2.2.4
>   cd guile-2.2.4/
>   git checkout v2.2.4
>   git checkout -b guile-2.2.4
>   sh autogen.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) 2.2.6.1-a69b5
>
> 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 libguile-2.2.so.1.4.1 from 2.2.6 that you installed earlier.
The libguile from guile 2.2.4 is libguile-2.2.so.1.3.1.

This happens because you never uninstalled the newer
libguile-2.2.so.1.4.1, and the library versioning information that we
assigned indicates that libguile-2.2.so.1.4.1 is a drop-in replacement
for libguile-2.2.so.1.3.1.  In other words, to our knowledge, any
executable linked with libguile-2.2.so.1.3.1 should also work properly
when linked with libguile-2.2.so.1.4.1.  That's because we added new
interfaces but did not change or remove any existing interfaces.

If you want to prevent libguile-2.2.so.1.4.1 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, libguile-2.2.so.1 and
libguile-2.2.so should be symlinks to libguile-2.2.so.1.3.1.

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, and finally "ldconfig" as root.

       Best,
        Mark

Re: Problem installing the intended version

[Thomas Morley]

Hi Mark,

Am Fr., 9. Aug. 2019 um 19:51 Uhr schrieb Mark H Weaver <mhw@netris.org>:
>
> Hi Thomas,
>
> Thomas Morley <thomasmorley65@gmail.com> 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://git.sv.gnu.org/guile.git ~/guile-2.2.4
> >   cd guile-2.2.4/
> >   git checkout v2.2.4
> >   git checkout -b guile-2.2.4
> >   sh autogen.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) 2.2.6.1-a69b5
> >
> > 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 libguile-2.2.so.1.4.1 from 2.2.6 that you installed earlier.
> The libguile from guile 2.2.4 is libguile-2.2.so.1.3.1.
>
> This happens because you never uninstalled the newer
> libguile-2.2.so.1.4.1, and the library versioning information that we
> assigned indicates that libguile-2.2.so.1.4.1 is a drop-in replacement
> for libguile-2.2.so.1.3.1.  In other words, to our knowledge, any
> executable linked with libguile-2.2.so.1.3.1 should also work properly
> when linked with libguile-2.2.so.1.4.1.  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.
Correct?

> If you want to prevent libguile-2.2.so.1.4.1 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, libguile-2.2.so.1 and
> libguile-2.2.so should be symlinks to libguile-2.2.so.1.3.1.
>
> 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/libguile-2.0.so.22.8.1-gdb.scm is
not an ELF file - it has the wrong magic bytes at the start.
/sbin/ldconfig.real: /usr/local/lib/libguile-2.2.so.1.3.1-gdb.scm 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
https://lists.gnu.org/archive/html/guile-devel/2018-07/msg00036.html
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.

Cheers,
  Harm

Re: Problem installing the intended version

[Mark H Weaver]

Hi Thomas,

Thomas Morley <thomasmorley65@gmail.com> writes:

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

Yes.

>> and finally "ldconfig" as root.
>
> Doing so I get:
> /sbin/ldconfig.real: /usr/local/lib/libguile-2.0.so.22.8.1-gdb.scm is
> not an ELF file - it has the wrong magic bytes at the start.
> /sbin/ldconfig.real: /usr/local/lib/libguile-2.2.so.1.3.1-gdb.scm 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?

Yes.  The warnings are harmless, although mildly annoying.

The issue is that GDB wants us to put that .scm file in the same
directory as libguile, in order to have GDB auto-load Guile debugging
support for executables linked with libguile.  See section 23.4.1 (The
'OBJFILE-gdb.EXT' file) in "Debugging with GDB":

  https://sourceware.org/gdb/current/onlinedocs/gdb/objfile_002dgdbdotext-file.html

Unfortunately, 'ldconfig' warns about it.  I seem to recall that we
reported the problem to the GDB developers at some point in the past.
Nowadays, most of the Guile developers seem to be using GNU Guix, where
'ldconfig' is never run, so we tend to forget about it.

     Regards,
       Mark