Hi Mark, Am Fr., 9. Aug. 2019 um 19:51 Uhr schrieb Mark H Weaver <m...@netris.org>: > > Hi Thomas, > > Thomas Morley <thomasmorle...@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
