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. -- [email protected] https://openlilylib.org http://lilypondblog.org _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
