Re: Request for build modification of gs in lilypond

[Graham Percival]

On Wed, Dec 08, 2010 at 09:06:22PM -0700, Henry Flurry wrote:
>    James & I have been in discussions on gs behavior if it ends up being
>    executed outside of the lilypond environment, in OS X.

Sorry, I'm confused.

First: please keep bug reports or feature requests on the
bug-lilypond mailing list.

Second: just to confirm, can you run lilypond normally?


more below

>    In OS X, if gs ends up on the $PATH and your run it directly, it crashes
>    in a failure to find a required dynamic library, unless the appropriate
>    path is added to $DYLD_LIBRARY_PATH:
>    
> -----------------------------------------------------------------------------------------------
>    bash-3.2$ env
>    ...
>    
> PATH=/Applications/_AudioMusicRelated/LilyPond.app/Contents/Resources/bin:/opt/local/bin:/opt/local/sbin:/opt/ooRexx/bin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin
>    PWD=/Users/flurry
>    LANG=en_US.UTF-8
>    SHLVL=2
>    HOME=/Users/flurry
>    OSTYPE=darwin
>    DYLD_LIBRARY_PATH=/opt/ooRexx/lib/ooRexx
>    VENDOR=apple
>    MACHTYPE=x86_64
>    ...
>    bash-3.2$ which gs
>    /Applications/_AudioMusicRelated/LilyPond.app/Contents/Resources/bin/gs
>    bash-3.2$ gs
>    dyld: Library not loaded: ./bin/../sobin/libgs.8.70.dylib
>      Referenced from:
>    /Applications/_AudioMusicRelated/LilyPond.app/Contents/Resources/bin/gs
>      Reason: image not found
>    Trace/BPT trap
>    bash-3.2$ export 
> DYLD_LIBRARY_PATH=/Applications/_AudioMusicRelated/LilyPond.app/Contents/Resources/lib:$DYLD_LIBRARY_PATH
>    bash-3.2$ gs
>    GPL Ghostscript 8.70: Can't find initialization file gs_init.ps.
>    bash-3.2$ 
>    
> -----------------------------------------------------------------------------------------------
>    gs does not crash from within the lilypond executable because the lilypond
>    executable sets the environment $DYLD_LIBRARY_PATH to point to lib.
>    I discovered this bug when using the newest version of LyX.  I added the
>    lilypond bin directory to the beginning of my PATH preferences within LyX,
>    and LyX in turn called lilypond's gs when processing lilypond's code.
>     This of course crashed, and left LyX with an unusable image in its
>    window.

Ok.  Why not set $DYLD_LIBRARY_PARTH within LyX ?

>  By rearranging the PATH preference so that LyX checked lilypond's
>    bin last, I was able to convince LyX to use a different gs.

This is not recommended; a different version of ghostscript might
have unexpected bugs... or they might have fixed some bug which
(by accident) we use.

The whole reason that we distribute our own version of ghostscript
on OSX is so that we have a known gs.

>    Because gs is a commonly used application, I am arguing that the
>    lilypond's version of gs should run properly as a standalone executable.
>    It appears to be an easy build option, because in the gs makefiles, there
>    are two variables which set the dynamic library to be "sobin."  If this
>    variable were to be set to "lib", which is where all of lilypond's other
>    dynamic linked libraries are, I suspect that gs would work properly.

1. would this change the size of the resulting binary?
2. could you supply a patch for GUB?

If you can run lilypond normally, then I'm afraid that such a
change has fairly low priority.  If somebody can provide a patch,
I'm willing to test it, but if not, it could take months (or even
years) before anybody looks at it.


>    Two other options for preventing folks from running this non-working
>    version of gs outside of lilypond:

Wait -- gs is working just fine.  You're trying to use our
installation of gs for tasks which it was not intended to be used
for.

>    - Move all of the child executables that are not to be called directly
>    into a subdirectory of lilypond's bin, so that it does not appear in the
>    $PATH anywhere.

I'm not completely opposed to that, but at the moment I think it
would complicate things.  I mean, there has to be some reason why
they're in the bin/ to begin with!
If you can provide a patch which does this, and which does not
harm any normal operation of lilypond, then we'll certainly look
at it.

>    - Rename them to something else that folks would not run.
>    Of course, the immediate way around this is to arrange your $PATH variable
>    so another gs is used instead of the gs within lilypond.  But, again, I
>    think that if you are distributing an another's executable that is meant
>    to be run alone (e.g., gs), it should function properly alone without
>    setting of rarely used environment variables.

Again, our installation of gs is not intended to be run by itself.
It is intended to be used in conjunction with lilypond, and that
appears to be working.

Cheers,
- Graham