bug-lilypond
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]