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
