Re: LD_LIBRARY_PATH in different installation contexts

[Urs Liska]

Hi David,

thank you for the feedback.


Am 11.04.2017 um 16:47 schrieb David Wright:
> On Tue 11 Apr 2017 at 11:04:14 (+0200), Urs Liska wrote:
>> I want to finally fix an issue in Frescobaldi that has bugged me for a
>> long time, but I need some information on how LilyPond behaves in
>> different installation types/contexts.
>>
>> For some time we had popping up reports about compilation failures
>> similar to this one
>>
>> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
>> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
>> -r1200 -sDEVICE=pdfwrite -sOutputFile=An-Silvia.pdf -c.setpdfwrite
>> -f/tmp/lilypond-tBFN9M)' failed (256)
>>
>> fatal error: failed files:
>> "/home/uliska/git/uliska/notensatz/an-silvia/An-Silvia.ly"
>>
>> The reason we determined is an incompatibility between LIlyPond's
>> built-in and system-provided versions of libraries (e.g. GhostScript).
>> The reason why this actually occurs as a problem is Frescobaldi's way to
>> support multiple installations: finding the executable and directly
>> invoking it instead of passing LilyPond's library path with it. So I
>> want to fix that now, but I don't know how this issue is actually
>> relevant to the different installations one may have.
> It might be worth making sure your tests include filenames containing
> spaces (perhaps even the odd Unicode char). I mentioned this in
> http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00589.html
> but I haven't pursued this; there does seem to be a quoting issue.
> I've never observed the font problem mentioned there myself.
>
>> Please give me some information about the following situations:
>>
>> a) Linux, downloaded binary release
>> Here the installation script creates a wrapper script "lilypond". This
>> includes the line "export LD_LIBRARY_PATH=<path/to/lilypond/usr/lib>"
>> This is what makes LilyPond use the bundled library versions instead of
>> the system-provided ones.
>>
>> Note that invoking the "lilypond" executable without that wrapper
>> doesn't necessarily cause the failure but only when the system libs
>> don't match the bundled ones. (For this case I don't need feedback, this
>> is what I "know". The solution is to pass this path to the lilypond
>> invocation.)
> I did try to look at what was happening with this error earlier in the month
> http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00326.html
> but didn't get very far. I was looking at the places the interpreter
> sought its libraries, and how the major and minor version numbers
> affected this, but couldn't see the pattern. It may be necessary to
> divine its intentions from the source code.

Maybe there are different issues here, maybe not.
But what I can say is that one problem I have found and that my patch
hopefully fixes is that a regular LilyPond installation through the
LInux installation script creates a wrapper script, and this sets the
LD_LIBRARY_PATH to a directory inside the LilyPond installation. If the
LilyPond executable is invoked directly this doesn't take place and a
default system version will be called.

So if this system version doesn't match LilyPond's expectations there
may errors like the infamous Ghostscript one, and I think this is *not*
related to spaces or fonts (although these may raise other independent
issues).

This is not tied to any absolute LilyPond or Ghostscript versions, but
in a way to the natural aging process of your OS environment.

What my patch does is find the library path for the used LilyPond
executable and sets the LC_LIBRARY_PATH environment variable
accordingly. I successfully tested that it fixed the issue for me.
I have a 2.19.41 installation where /usr/lib/ghostscript points to 9.15
while the more recent versions point to 9.20.
gs -v shows that by default 9.20 is used on my system, and consequently
running LilyPond 2.19.41 without the explicit library path gives the
Ghostscript failure.
*With* the patch the library path points to the /usr/lib of 2.19.41, and
obviously it then correctly invokes Ghostscript 9.15.

>
>> b) Linux, self-compiled
>> I've never experienced this issue with self-compiled LilyPonds. I assume
>> this is *not* because self-compiled versions implicitly use the bundled
>> libs but because they implicitly compile against what is available in
>> the system. But if that assumption is correct I'd experience the same
>> issue if I should run a self-compiled Lilypond that has been compiled
>> some time ago, e.g. before a major Linux upgrade.
>>
>> c) Linux, distro package
>> I have no idea how packaged versions deal with that issue. Is there a
>> wrapper script too, and what does that do? (I can't install such a
>> version to test because on Debian testing there still is "no
>> installation candidate for package lilypond").
> Presumably you're running stretch where the lilypond is currently dry.

Yes.

> You're probably familiar with 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746005
> I don't know if that is the reason that sid (most up-to-date) still
> has version 2.18.2, the same as jessie (the current stable Debian).

I don't think so. LilyPond has been currently kicked out of Debian
stretch because they removed Guile 1.8 (which is also the reason why I
can't compile LilyPond myself at the moment).

Choosing between stable and devel releases of LilyPond is probably more
a decision about being more or less conservative with package versions.

Best

Urs

>
> But anyway, the point of distro-packaged versions on Debian-style
> distributions (ie non-rolling release) is that the libraries should be
> consistent, with no need for wrappers. That's true for jessie and
> wheezy (oldstable). So rolling-release people probably need to comment
> on this separately.
>  
>> d) Mac
>> No idea about that. How is LilyPond installed and invoked there? Is that
>> compatibility an issue in the first place?
>>
>> e) Windows
>> I can imagine this isn't an issue because everything has to be bundled
>> anyway. But I don't know about that.
>>
>> Please help me by giving me that information. It is an embarrassing and
>> annoying bug in Frescobaldi, and I'd like to get rid of it. Of course I
>> can do it so it "works for me", but of course it should be done better.
> Cheers,
> David.

-- 
address@hidden
https://openlilylib.org
http://lilypondblog.org