[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for build modification of gs in lilypond
From: |
Graham Percival |
Subject: |
Re: Request for build modification of gs in lilypond |
Date: |
Thu, 9 Dec 2010 14:02:58 +0000 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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