Re: ghostscript fails on pdf generation

[David Wright]

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.