[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Request for build modification of gs in lilypond - case closed?
From: |
Henry Flurry |
Subject: |
Re: Request for build modification of gs in lilypond - case closed? |
Date: |
Fri, 10 Dec 2010 09:15:22 -0700 |
> Again, please keep the discussion on the mailing list.
>
Whoops. Please accept my apologies, Graham.
This is probably my final follow up to the following situation:
- in OS X, if the lilypond .../bin ends up in the $PATH of a user or
application, then at least one of the executables (gs) that is likely to be
called by an unsuspecting user will crash when executed directly. (Note -
lilypond functions fine. Only gs fails if called directly by the user or
another process not in the lilypond distribution.)
- I discovered this from integrating lilypond 2.13 with LyX Beta 2.0. The
directions posted on the lilypond-user list were to put the lilypond .../bin
into the PATH for LyX, in order for LyX to find and run lilypond.
- Because LyX called gs directly, it ended up calling lilypond's gs instead of
another installed gs (I had put lilypond's .../bin at the beginning of LyX's
path specification). This, of course, failed, because in the lilypond
distribution, gs is compiled to look for its dynamic libraries in a
non-existant directory (.../sobin). Lilypond gets around this by setting the
environment variable DYLD_LIBRARY_PATH to point to lilypond's .../lib folder,
which is where gs's dynamic library resides (even though it is hard coded to
look first in .../sobin).
- My initial solution to the LyX/lilypond integration problem was to move
lilypond's .../bin to the end of LyX's PATH settings.
My earlier feature request was that GUB be modified to override gs's makefile
default setting of SOBINRELDIR=../sobin to set it to: SOBINRELDIR=../lib so
that gs would not crash when executed by a user or process not part of the
lilypond distribution set.
While I still think that the above change would remove some internal
inconsistencies in the delivered executable, and it might remove lilypond's
necessity to set the DYLD_LIBRARY_PATH environment variable, it turns out that
I had not completed the installation appropriately. As Graham pointed out:
> 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".
>
So ... there's the crux. I had missed that.
When I set this up, everything works as promised. There is no rogue gs in my
$PATH, and LyX will work properly using these scripts instead of pointing
directly to the executables in lilypond's .../bin directory. As far as LyX is
concerned, my lilypond installation is in ~/bin.
I have posted on the lilypond-user email list on directions on setting up LyX
with lilypond that use the script method, rather than the link to the direct
path.
**************
FINAL FOLLOW UP QUESTION
Is this how you intend lilypond to be accessed by other processes? Through the
scripts in ~/bin?
**************
Graham says above that you should never put lilypond bin/ in your PATH. But
the guidelines seem different if lilypond is to be used by other processes:
much of the lilypond documentation talks of putting the path to the lilypond
.../bin into various .* files or preferences, such as .vimrc.
However, my impression now is that for OS X, at least, it should be the ~/bin
that is added to LyX's path or .vimrc or other .* files, not lilypond's
.../bin, so that the scripts are accessed and not the executables directly.
Thanks!
Henry Flurry
Music Flash Class - a music flash card app for iPhone/iPod Touch versatile
enough for your teaching
www.MusicFlashClass.com
Thanks!
Henry Flurry
- Re: Request for build modification of gs in lilypond - case closed?,
Henry Flurry <=