lilypond-user
[Top][All Lists]
Advanced

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

Re: Which Linux distro for Lilypond


From: Knut Petersen
Subject: Re: Which Linux distro for Lilypond
Date: Wed, 11 Jan 2017 09:08:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

Hi Werner!
*If* we bundle guile 1.8 with lilypond, I strongly prefer static
linking of the library (this is, adding `--disable-shared' to guile's
configure script, together with a proper argument to the
`--datarootdir' option to install the .scm files under a lilypond
directory).  This avoids *any* problems with different guile library
versions, and the created lilypond binary can peacefully coexist with
guile 2.0 even in the `/usr' tree.

Using a guile 1.8.8 built with --disable-shared building of lilypond fails early:

chmod 755 out/lilypond-invoke-editor
echo /home/knut/sources/lily/build/scripts/build/out/help2man
/home/knut/sources/lily/build/scripts/build/out/help2man
/home/knut/sources/lily/build/scripts/build/out/help2man out/lilypond-invoke-editor > out/lilypond-invoke-editor.1
help2man: can't get `--help' info from out/lilypond-invoke-editor
Try `--no-discard-stderr' if option outputs to stderr
Running build/scripts/out/lilypond-invoke-editor gives a hint:

ERROR: In procedure dynamic-link:
ERROR: file: "libguile-srfi-srfi-1-v-3", message: "file not found"
Ok, we don't really need it, so a brutal fix is to simply remove the srfi modules from that file... that works.

After that the build does not succeed, but it fails after building the binary.

Executing the lilypond binary gives
GNU LilyPond 2.19.55
/home/knut/sources/guile18built/share/guile/1.8/srfi/srfi-1.scm:223:1: In procedure dynamic-link in _expression_ (load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"):
/home/knut/sources/guile18built/share/guile/1.8/srfi/srfi-1.scm:223:1: file: "libguile-srfi-srfi-1-v-3", message: "file not found"
Ok, let's look at srfi-1.scm line 221..223:
;; Load the compiled primitives from the shared library.
;;
(load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1")
Could it be that --disable-shared kills support of required modules? Is there a known workaround?

cu,
 Knut

reply via email to

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