They say on the Bug-Libtool list that the behavior might be changed
using 'install_name_tool'.
Hans
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
I have done some more debugging, and the result is surprising:
When I move only /usr/local/lib/libltdl.7.dylib to another name, then
lilypond works; however, dtruss shows that it calls /usr/lib/libltdl.
7.dylib !
So lilypond may never have called
/Applications/LilyPond.app/Contents/Resourc
Addition:
The Guile manual, sec. 4.2.1, says:
It will look in the places that are usual for your operating
system, and it
will additionally look into the directories listed in the
LTDL_LIBRARY_PATH
environment variable.
So guile is probably hardwired to look into /usr/local/lib/. It m
One can use 'dtruss lilypond empty', which the writes the stuff below.
So for some reason, lilypond does call stuff in /usr/local/lib/. And
it seems, as I thought, that it is libltdl that is the problem - I
used a different version.
The Guile manual, sec. 4.2.1, says that it uses LTDL_LIBRA
On 4 Feb 2010, at 04:59, Stan Sanderson wrote:
I just tested it on my PPC 10.5.8 with Lily 2.13.10. It was a
relatively short .ly file, but there were no errors reported.
Tested what?
My apologies if it wasn't clear that I compiled a .ly source file
using Lilypond 2.13.10 without moving a
On Feb 3, 2010, at 5:44 PM, Hans Aberg wrote:
On 4 Feb 2010, at 00:13, Stan Sanderson wrote:
It seems that the 'lilypond' that is inside LilyPond.app*) on Mac
OS X (tried on 10.5.8) calls stuff in /usr/local/ which can cause
the program to fail by segmentation fault:
I just updated to gu
It may have to do with libtool, which has libltdl which Guile calls
when doing the extensibility stuff. I used libtool-2.2.6b when making
guile. So if LilyPond's guile was made with another version, but calls
stuff outside it directory, that might cause it.
Hans
__
On 4 Feb 2010, at 00:47, James Bailey wrote:
This may have to do with the order of things in your $PATH.
Possibly, unless 'lilypond' sets its own. But why is 'lilypond'
calling it? Library paths are hardcoded. And calling stuff that comes
with the OS should be called using full paths if it
On 4 Feb 2010, at 00:13, Stan Sanderson wrote:
It seems that the 'lilypond' that is inside LilyPond.app*) on Mac
OS X (tried on 10.5.8) calls stuff in /usr/local/ which can cause
the program to fail by segmentation fault:
I just updated to guile-1.8.7 and gmp-4.3.1, and then both LilyPond
On 04.02.2010, at 00:13, Stan Sanderson wrote:
On Feb 3, 2010, at 4:20 PM, Hans Aberg wrote:
It seems that the 'lilypond' that is inside LilyPond.app*) on Mac
OS X (tried on 10.5.8) calls stuff in /usr/local/ which can cause
the program to fail by segmentation fault:
I just updated to g
On Feb 3, 2010, at 4:20 PM, Hans Aberg wrote:
It seems that the 'lilypond' that is inside LilyPond.app*) on Mac OS
X (tried on 10.5.8) calls stuff in /usr/local/ which can cause the
program to fail by segmentation fault:
I just updated to guile-1.8.7 and gmp-4.3.1, and then both LilyPond
It seems that the 'lilypond' that is inside LilyPond.app*) on Mac OS X
(tried on 10.5.8) calls stuff in /usr/local/ which can cause the
program to fail by segmentation fault:
I just updated to guile-1.8.7 and gmp-4.3.1, and then both LilyPond
2.13.7 and 2.13.11 failed - segmentation fault e
12 matches
Mail list logo