ghostscript fails on pdf generation

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ghostscript fails on pdf generation

N. Andrew Walsh
Hi List,

I realize this isn't strictly an issue with Lily, but pdf output recently started failing. I see the following message in the console output:

Layout output to `/tmp/lilypond-CFV9h3'...
Converting to `Reinhold Urmetzer - Lamento di Achille.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=Reinhold Urmetzer - Lamento di Achille.pdf -c.setpdfwrite -f/tmp/lilypond-CFV9h3)' failed (256)

'gs' is the ghostscript binary, but I haven't updated that recently, nor any of its dependencies (the closest I could find in recent updates was "podofo", which seems only marginally related to pdf generation). 

Is there a way to check what the exact error might be here? I suspect a recent package update somewhere changed a shared library and I'll need to recompile something, but I'm not sure what. Any suggestions?

Cheers,

A

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

N. Andrew Walsh
PS- ghostscript on my system (gentoo Linux) recently updated: on Jan 31st to 9.20-r1. Can anybody else check and see if they encounter the same issue with that version of ghostscript? Trawling back through old github issues and forum archives shows a number of times over the years where a ghostscript update changed some part of the code and Lily wasn't yet adapted. For the record, I'm running Lilypond-2.19.54-1, 64-bit.

On Sat, Feb 11, 2017 at 8:36 PM, N. Andrew Walsh <[hidden email]> wrote:
Hi List,

I realize this isn't strictly an issue with Lily, but pdf output recently started failing. I see the following message in the console output:

Layout output to `/tmp/lilypond-CFV9h3'...
Converting to `Reinhold Urmetzer - Lamento di Achille.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=Reinhold Urmetzer - Lamento di Achille.pdf -c.setpdfwrite -f/tmp/lilypond-CFV9h3)' failed (256)

'gs' is the ghostscript binary, but I haven't updated that recently, nor any of its dependencies (the closest I could find in recent updates was "podofo", which seems only marginally related to pdf generation). 

Is there a way to check what the exact error might be here? I suspect a recent package update somewhere changed a shared library and I'll need to recompile something, but I'm not sure what. Any suggestions?

Cheers,

A


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Jean Brefort
Le samedi 11 février 2017 à 20:55 +0100, N. Andrew Walsh a écrit :

> PS- ghostscript on my system (gentoo Linux) recently updated: on Jan
> 31st to 9.20-r1. Can anybody else check and see if they encounter the
> same issue with that version of ghostscript? Trawling back through
> old github issues and forum archives shows a number of times over the
> years where a ghostscript update changed some part of the code and
> Lily wasn't yet adapted. For the record, I'm running Lilypond-
> 2.19.54-1, 64-bit.
>
> On Sat, Feb 11, 2017 at 8:36 PM, N. Andrew Walsh <n.andrew.walsh@gmai
> l.com> wrote:
> > Hi List,
> >
> > I realize this isn't strictly an issue with Lily, but pdf output
> > recently started failing. I see the following message in the
> > console output:
> >
> > Layout output to `/tmp/lilypond-CFV9h3'...
> > Converting to `Reinhold Urmetzer - Lamento di Achille.pdf'...
> > warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
> > -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
> > -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=Reinhold Urmetzer -
> > Lamento di Achille.pdf -c.setpdfwrite -f/tmp/lilypond-CFV9h3)'
> > failed (256)
> >
> > 'gs' is the ghostscript binary, but I haven't updated that
> > recently, nor any of its dependencies (the closest I could find in
> > recent updates was "podofo", which seems only marginally related to
> > pdf generation). 
> >
> > Is there a way to check what the exact error might be here? I
> > suspect a recent package update somewhere changed a shared library
> > and I'll need to recompile something, but I'm not sure what. Any
> > suggestions?
> >
> > Cheers,
> >
> > A
> >
Hi,

I get that for large score because of not enough RAM.

Regards,
Jean

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

N. Andrew Walsh
Hi Jean,

I have 32GB of RAM. I have never seen that tick over 20% use, for anything, so I don't think it's an issue with memory.

Cheers,

A

On Sat, Feb 11, 2017 at 9:08 PM, Jean Brefort <[hidden email]> wrote:
Le samedi 11 février 2017 à 20:55 +0100, N. Andrew Walsh a écrit :
> PS- ghostscript on my system (gentoo Linux) recently updated: on Jan
> 31st to 9.20-r1. Can anybody else check and see if they encounter the
> same issue with that version of ghostscript? Trawling back through
> old github issues and forum archives shows a number of times over the
> years where a ghostscript update changed some part of the code and
> Lily wasn't yet adapted. For the record, I'm running Lilypond-
> 2.19.54-1, 64-bit.
>
> On Sat, Feb 11, 2017 at 8:36 PM, N. Andrew Walsh <n.andrew.walsh@gmai
> l.com> wrote:
> > Hi List,
> >
> > I realize this isn't strictly an issue with Lily, but pdf output
> > recently started failing. I see the following message in the
> > console output:
> >
> > Layout output to `/tmp/lilypond-CFV9h3'...
> > Converting to `Reinhold Urmetzer - Lamento di Achille.pdf'...
> > warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
> > -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
> > -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=Reinhold Urmetzer -
> > Lamento di Achille.pdf -c.setpdfwrite -f/tmp/lilypond-CFV9h3)'
> > failed (256)
> >
> > 'gs' is the ghostscript binary, but I haven't updated that
> > recently, nor any of its dependencies (the closest I could find in
> > recent updates was "podofo", which seems only marginally related to
> > pdf generation). 
> >
> > Is there a way to check what the exact error might be here? I
> > suspect a recent package update somewhere changed a shared library
> > and I'll need to recompile something, but I'm not sure what. Any
> > suggestions?
> >
> > Cheers,
> >
> > A
> >
Hi,

I get that for large score because of not enough RAM.

Regards,
Jean


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Noeck
In reply to this post by N. Andrew Walsh
Hi Andrew,

Am 11.02.2017 um 20:36 schrieb N. Andrew Walsh:
> -sOutputFile=Reinhold Urmetzer - Lamento di Achille.pdf

Does it also happen when the file name does not contain spaces?
The part above from your quoted gs command is likely not working if
executed exactly like this.
-sOutputFile="Reinhold Urmetzer - Lamento di Achille.pdf" has better
chances. You can test with a file name containing only letters for instance.

HTH,
Joram

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

N. Andrew Walsh
Hi Joram,

Does it also happen when the file name does not contain spaces?

yes, it does. I tried with a renamed file, and got the same error.

Cheers,



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Simon Albrecht-2
On 11.02.2017 21:20, N. Andrew Walsh wrote:
> Hi Joram,
>
>
>     Does it also happen when the file name does not contain spaces?
>
>
> yes, it does. I tried with a renamed file, and got the same error.

I think you can report this to the bug list. Even if it’s not strictly a
LilyPond issue, we might investigate the exact source of the problem.
If the issue depends on what file you are running, please include a
minimal example, else just your exact setup.

Best, Simon

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Thomas Morley-2
2017-02-11 23:40 GMT+01:00 Simon Albrecht <[hidden email]>:

> On 11.02.2017 21:20, N. Andrew Walsh wrote:
>>
>> Hi Joram,
>>
>>
>>     Does it also happen when the file name does not contain spaces?
>>
>>
>> yes, it does. I tried with a renamed file, and got the same error.
>
>
> I think you can report this to the bug list. Even if it’s not strictly a
> LilyPond issue, we might investigate the exact source of the problem.
> If the issue depends on what file you are running, please include a minimal
> example, else just your exact setup.
>
> Best, Simon
>
>
> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user

I tested the minimal:
{ c'1 }
with self-compiled 2.19.55 and Ghostscript 9.20 (2016-09-26) and guile 2.0.13
No issue.

AFAIK GUB uses gs 9.20 as well.

Do you use a lilypond via the installer or self-compiled?
Does the minimal above fail as well?
If not, please try to get a minimal example reducing your score and
post it here.


Cheers,
  Harm

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

David Wright
In reply to this post by N. Andrew Walsh
On Sat 11 Feb 2017 at 20:36:33 (+0100), N. Andrew Walsh wrote:

> I realize this isn't strictly an issue with Lily, but pdf output recently
> started failing. I see the following message in the console output:
>
> Layout output to `/tmp/lilypond-CFV9h3'...
> Converting to `Reinhold Urmetzer - Lamento di Achille.pdf'...
> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
> -r1200 -sDEVICE=pdfwrite -sOutputFile=Reinhold Urmetzer - Lamento di
> Achille.pdf -c.setpdfwrite -f/tmp/lilypond-CFV9h3)' failed (256)
>
> 'gs' is the ghostscript binary, but I haven't updated that recently, nor
> any of its dependencies (the closest I could find in recent updates was
> "podofo", which seems only marginally related to pdf generation).
>
> Is there a way to check what the exact error might be here? I suspect a
> recent package update somewhere changed a shared library and I'll need to
> recompile something, but I'm not sure what. Any suggestions?

I can't see any difference between that error message and the one
referred to in
http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00087.html
which I could duplicate myself as shown in
http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00123.html
where I avoid using the wrapper script that sets $LD_LIBRARY_PATH.

IOW you can get this by mixing versions of the various parts of the
LP system.

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Urs Liska


Am 12. Februar 2017 02:25:42 MEZ schrieb David Wright <[hidden email]>:

>On Sat 11 Feb 2017 at 20:36:33 (+0100), N. Andrew Walsh wrote:
>> I realize this isn't strictly an issue with Lily, but pdf output
>recently
>> started failing. I see the following message in the console output:
>>
>> Layout output to `/tmp/lilypond-CFV9h3'...
>> Converting to `Reinhold Urmetzer - Lamento di Achille.pdf'...
>> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
>> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE
>-dBATCH
>> -r1200 -sDEVICE=pdfwrite -sOutputFile=Reinhold Urmetzer - Lamento di
>> Achille.pdf -c.setpdfwrite -f/tmp/lilypond-CFV9h3)' failed (256)
>>
>> 'gs' is the ghostscript binary, but I haven't updated that recently,
>nor
>> any of its dependencies (the closest I could find in recent updates
>was
>> "podofo", which seems only marginally related to pdf generation).
>>
>> Is there a way to check what the exact error might be here? I suspect
>a
>> recent package update somewhere changed a shared library and I'll
>need to
>> recompile something, but I'm not sure what. Any suggestions?
>
>I can't see any difference between that error message and the one
>referred to in
>http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00087.html
>which I could duplicate myself as shown in
>http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00123.html
>where I avoid using the wrapper script that sets $LD_LIBRARY_PATH.
>
>IOW you can get this by mixing versions of the various parts of the
>LP system.
>

Does this error appear when you run lilypond from the command line or only when you run it from Frescobaldi?

IIRC I considered this as an issue with Frescobaldi because it doesn't set that Library path - which causes LilyPond to use the system's gs instead of its own copy, and this may work or not

Urs

>Cheers,
>David.
>
>_______________________________________________
>lilypond-user mailing list
>[hidden email]
>https://lists.gnu.org/mailman/listinfo/lilypond-user

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

N. Andrew Walsh
Hi Urs,

Does this error appear when you run lilypond from the command line or only when you run it from Frescobaldi?
 
This error occurs from the command line as well. It also failed to find the openlilylib installation, but that's just because I don't know how to add a search path from the command line. Regardless, I should also mention that I was able to compile the same file earlier (back in January), and hadn't done anything with Frescobaldi or Lily between then and now (well, except now I've upgraded Lily in an effort to fix the issue). 

David: how do you "avoid using the wrapper script"? And how do you work around this issue?

Cheers,

A

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Simon Albrecht-2
On 12.02.2017 09:15, N. Andrew Walsh wrote:
> I don't know how to add a search path from the command line.

That’s by using the -I command line option, which you might include in
an alias as well.

Best, Simon

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

David Wright
In reply to this post by N. Andrew Walsh
On Sun 12 Feb 2017 at 09:15:49 (+0100), N. Andrew Walsh wrote:

> > Does this error appear when you run lilypond from the command line or only
> > when you run it from Frescobaldi?
> This error occurs from the command line as well. It also failed to find the
> openlilylib installation, but that's just because I don't know how to add a
> search path from the command line. Regardless, I should also mention that I
> was able to compile the same file earlier (back in January), and hadn't
> done anything with Frescobaldi or Lily between then and now (well, except
> now I've upgraded Lily in an effort to fix the issue).
>
> David: how do you "avoid using the wrapper script"? And how do you work
> around this issue?

The first example on:
http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00123.html

$ ~/lilypond-2.19.42.1/bin/lilypond e.ly

runs this (now newer) script:

#!/bin/sh
me=`basename $0`
export LD_LIBRARY_PATH="/home/david/lilypond-2.19.49-1/lilypond/usr/lib"
exec "/home/david/lilypond-2.19.49-1/lilypond/usr/bin/$me" "$@"

whereas the second one runs what is in the exec line above, ie

/home/david/lilypond-2.19.49-1/lilypond/usr/bin/$me

which was

$ ~/lilypond-2.19.42.1/lilypond/usr/bin/lilypond e.ly

which was the 5MB binary downloaded.

The Debian version of LP installed on this machine is at least as
old as 2.18.2.

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

N. Andrew Walsh
Hi David,

The first example on:
http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00123.html

$ ~/lilypond-2.19.42.1/bin/lilypond e.ly

runs this (now newer) script:

#!/bin/sh
me=`basename $0`
export LD_LIBRARY_PATH="/home/david/lilypond-2.19.49-1/lilypond/usr/lib"
exec "/home/david/lilypond-2.19.49-1/lilypond/usr/bin/$me" "$@"

That's the command I used (ie, invoking Lily from its local /bin directory, and not its local /usr/bin), and it still failed with the error described. 

Cheers,


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

David Wright
On Sun 12 Feb 2017 at 19:38:47 (+0100), N. Andrew Walsh wrote:

> > The first example on:
> > http://lists.gnu.org/archive/html/lilypond-user/2016-06/msg00123.html
> >
> > $ ~/lilypond-2.19.42.1/bin/lilypond e.ly
> >
> > runs this (now newer) script:
> >
> > #!/bin/sh
> > me=`basename $0`
> > export LD_LIBRARY_PATH="/home/david/lilypond-2.19.49-1/lilypond/usr/lib"
> > exec "/home/david/lilypond-2.19.49-1/lilypond/usr/bin/$me" "$@"
> >
>
> That's the command I used (ie, invoking Lily from its local /bin directory,
> and not its local /usr/bin), and it still failed with the error described.

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.

In the case cited from June, the OP was using an odd system (eg it
used # as a *user* prompt) whose tar couldn't create symlinks when
it unpacked an archive (permissions messages); they had to be
created manually.

I don't know if their problem was ever satisfactorily concluded, but
they were certainly able to work around the problem by running gs
manually; easy to script with 2.18.2 because the .ps names are
predictable, less so with newer versons that use nonce filenames.

It might be halpful to know what error 256 means. Some people
report [ERROR] failed to set file mode for PDF file (non fatal),
but I've seen nothing to suggest that you couldn't get that
message just because there is no PDF file to chmod.

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

N. Andrew Walsh
Hi David,

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.

Thanks for the help,

A

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Wols Lists
In reply to this post by David Wright
On 12/02/17 19:59, David Wright wrote:
> In the case cited from June, the OP was using an odd system (eg it
> used # as a *user* prompt) whose tar couldn't create symlinks when
> it unpacked an archive (permissions messages); they had to be
> created manually.

I don't know when it started happening - maybe a year ago? - but I
suddenly found I couldn't symlink files. And I couldn't find anything
about it on the net, but as far as I have been able to make out ...

You need "rw" permissions on somebody else's files if you want to create
a hard link.

It seems daft to me that you need "w" permissions, and I haven't
experimented deeply with it, but if I have access to a file, why
shouldn't I be able to create a link to it?

I don't know how tar unpacking works particularly, but if it unpacks a
file, gives away ownership, and then tries to link to it, that could be
why that problem happened.

Cheers,
Wol

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

David Wright
On Sun 12 Feb 2017 at 21:03:01 (+0000), Wols Lists wrote:

> On 12/02/17 19:59, David Wright wrote:
> > In the case cited from June, the OP was using an odd system (eg it
> > used # as a *user* prompt) whose tar couldn't create symlinks when
> > it unpacked an archive (permissions messages); they had to be
> > created manually.
>
> I don't know when it started happening - maybe a year ago? - but I
> suddenly found I couldn't symlink files. And I couldn't find anything
> about it on the net, but as far as I have been able to make out ...
>
> You need "rw" permissions on somebody else's files if you want to create
> a hard link.
>
> It seems daft to me that you need "w" permissions, and I haven't
> experimented deeply with it, but if I have access to a file, why
> shouldn't I be able to create a link to it?

Because it's a security risk. Geriatric unixers might wonder why their
suid scripts no longer work: similar reasons.

https://lwn.net/Articles/502621/

> I don't know how tar unpacking works particularly, but if it unpacks a
> file, gives away ownership, and then tries to link to it, that could be
> why that problem happened.

One is always at the mercy of what is reported, but the OP was able to
create all the correct symlinks themselves as the same user. Suspicion
fell on tar because of entries in the change log. One can't help
wondering about the admin of a system that sets # as the user prompt.

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

David Wright
In reply to this post by N. Andrew Walsh
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: ghostscript fails on pdf generation

Wols Lists
In reply to this post by David Wright
On 13/02/17 15:23, David Wright wrote:
>> It seems daft to me that you need "w" permissions, and I haven't
>> > experimented deeply with it, but if I have access to a file, why
>> > shouldn't I be able to create a link to it?
> Because it's a security risk. Geriatric unixers might wonder why their
> suid scripts no longer work: similar reasons.
>
> https://lwn.net/Articles/502621/
>
Thank you very much indeed. I've relaxed hardlink security on my machine
(well, hopefully next time I boot), and starred your email for reference :-)

Cheers,
Wol

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
12