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 _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
