Re: LD_LIBRARY_PATH in different installation contexts

[Urs Liska]

I don't know why the previous email was formatted so badly, I'll try it again

Hi all,

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.

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.)

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").

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.

Urs

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