Re: Request for build modification of gs in lilypond

[Graham Percival]

Again, please keep the discussion on the mailing list.

I disagree with your "proper behaviour", since you should never
put the lilypond bin/ directory in your PATH.  For help settng up
lilypond, see:
http://lilypond.org/macos-x.html
"macosx on the command line".

I am not opposed to considering a patch which modifies the
ghostscript build in GUB, although I'm not yet convinced that this
is needed.

Hopefully a bug squad member will open an issue for this.  That
issue should contain a link to this discussion in the archives,
along with the above warning from me.

Cheers,
- Graham

On Thu, Dec 09, 2010 at 06:21:23AM -0700, Henry Flurry wrote:
>    Sorry for not being clear.
>    This was reported to bug-lilypond, went into discussion with James, and
>    eventually was directed to you.
>    lilypond (2.13) runs fine.
>    gs, in your distribution, does not run fine standalone, since the variable
>    setting SOBINRELDIR=../sobin in the gs makefiles does not point to a valid
>    directory in the lilypond OS X distribution.
>    lilypond gets around this by setting an environment
>    variable DYLD_LIBRARY_PATH to point to ../lib, which is where the dynamic
>    library for gs is placed.
>    Two workarounds for the user: put lilypond at the end of the $PATH and use
>    a different gs distribution, or set DYLD_LIBRARY_PATH to point to the
>    lilypond dynamic lib path.  The latter work around does NOT work for other
>    executables that call gs and do not set up DYLD_LIBRARY_PATH.
>    I argue that, because gs is a well known and stable piece of software, the
>    proper behavior for a standalone execution of gs is to work properly "out
>    of the box," or you should hide it so that it will not be executed by
>    other users or processes.
>    Not knowing GUB well enough to put in the fix myself, I'm proposing that
>    someone change GUB to build gs with an override makefile variable set
>    to: SOBINRELDIR=../lib
>    Thanks,
>    Henry
>    On Dec 9, 2010, at 5:20 AM, Graham Percival wrote:
> 
>      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