lilypond-user
[Top][All Lists]
Advanced

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

Re: LD_LIBRARY_PATH in different installation contexts


From: David Wright
Subject: Re: LD_LIBRARY_PATH in different installation contexts
Date: Tue, 11 Apr 2017 09:47:14 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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.

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

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.



reply via email to

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