On Sun 12 Feb 2017 at 21:17:54 (+0100), N. Andrew Walsh wrote: > > > > The import of my post was to raise the question of whether the parts > > of your LP system are incompatible and, if so, whether that was > > brought about by the source of your LP system (which would probably > > affect many people) or just a problem in your own setup. > > > Well, the best I can do is say that I downloaded the most recent tarball > into ~/[$lilypond-dir], ran /[$lilypond-dir]/bin/uninstall-lilypond, and > then installed the new tarball with 'sh lilypond-2.19.54-1.linux-64.sh > --prefix [$lilypond-dir]/'. (there's actually another option I remember > having as part of the tarball install, but I can neither remember it nor > find it in the console buffer or under --help). > > That should have installed a self-contained Lily install, yes? And I would > repeat here the addendum I made to my first message: I was able to use > lilypond-2.19.52 without error mid-January, and was unable to do so after > updating some packages (including ghostscript). But if Lily is using her > own internal invocation of ghostscript, that shouldn't even matter, right? > So I'm not sure wherein the problem lies.
The closest I got to tracking down this error was to find out why gs stopped with error 256. It does appear that people who link it with the missing PDF file are missing the point. I've run 2.19.49 the correct way, 2.19.49 the incorrect way (circumventing LD_LIBRARY_PATH), and 2.18.2 the incorrect way. The first and the last both succeed. The middle one fails, apparently because it runs the wrong gs interpreter. It tries to initialise with the correct file /home/david/lilypond-2.19.49-1/lilypond/usr/share/ghostscript/9.15/Resource/Init/gs_init.ps but then writes a 73 character string to file descriptor 1 which starts with: "gs: Interpreter revision (905) d" and will continue "oes not match gs_init.ps revision (915).\n". So if the middle run was running my Debian-installed gs 9.05, it would be happy to initialise with /usr/share/ghostscript/9.05/Resource/Init/gs_init.ps that contains: ✂ ✂ ✂ ✂ ✂ % Interpreter library version number % NOTE: the interpreter code requires that the first non-comment token % in this file be an integer, and that it match the compiled-in % version! 905 % Check the interpreter revision. dup revision ne { (gs: Interpreter revision \() print revision 10 string cvs print (\) does not match gs_init.ps revision \() print 10 string cvs print (\).\n) print flush //null 1 .quit } if pop ✂ ✂ ✂ ✂ ✂ So why is the failing version running gs 9.05 instead of the correct version 9.15? Here's where the water gets murky and I get out of my depth. The main difference I can see is: Soon after: execve("/home/david/lilypond-<whatever>/lilypond/usr/bin/../bin/gs" the failing version for some reason unexpectedly opens /etc/ld.so.cache within which it finds the strings: libgs.so.9 /usr/lib/libgs.so.9 so it opens /usr/lib/libgs.so.9, which is a Debian wheezy file; wrong version, ghostscript_9.05~dfsg-6.3+deb7u4. So the problem may boil down to having a Debian version of gs with the same *major* version number that's cached in /etc/ld.so.cache. But what I can't work out is why /etc/ld.so.cache is consulted so early after gs starts in only the failing run. Both the other runs only open it when searching for libc.so.6, which comes after finding libgs.so.9. Or, put the other way round, why does the third run (which circumvents LD_LIBRARY_PATH like the second) not consult /etc/ld.so.cache earlier? OK, it won't find libgs.so.8 in it and get thrown off course, but it doesn't even look. Perhaps some other change in the environment has already occurred that affects 2.19.49 but not 2.18.2. So to track this problem down, I think you either have to be familiar with the libraries involved and how LP determines which to open and when, or spend a lot of time examining the output of $ strace -f <versions>/<of>/lilypond ... Therein might be the answer as to why such failures happen even with the correct LD_LIBRARY_PATH. Cheers, David. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user