On Thu, Feb 04, 2010 at 04:21:27PM +0100, Hans Aberg wrote: >> When libtool support for Mac OS X was added, there was no way to load >> .dylib files, not much software had any knowledge of Mac OS X, and >> quite >> a lot of things had hardcoded ".so" when loading files at runtime, so >> to >> accomodate this, .so was chosen as the extension when creating >> loadable >> modules (MH_BUNDLE) and .dylib when creating MH_DYLIB. Changing >> this now would cause far too many problems. > > Not really: 10.4 and earlier are obsolete, and 10.5 is becoming. On > 10.5, just ordinary load is fine.
10.4 and earlier are not obsolete, sorry. >> So, long story short, ltld looks for ".so" because that is the >> extension >> used for loadable modules. > > Well, that is not a part of the UNIX standard, and therefore not POSIX, > which is nowadays a subset. Which part of POSIX standardizes library extensions? > ---- > $ lilypond empty.ly > dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ > lib//libintl.8.dylib > dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ > lib//libguile.17.dylib > dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ > lib//libltdl.7.dylib > GNU LilyPond 2.13.7 > dyld: loaded: /usr/local/lib/libguile-srfi-srfi-1-v-3.3.dylib > dyld: loaded: /usr/local/lib/libguile.17.dylib > dyld: loaded: /usr/local/lib/libintl.8.dylib > dyld: loaded: /usr/local/lib/libgmp.3.dylib > dyld: loaded: /usr/local/lib/libltdl.7.dylib > Segmentation fault So lilypond starts up fine, but guile's first dlopen() for libguile-srfi-srfi-1-v-3.3 causes the library in /usr/local/lib to be loaded (and its dependent libraries, including another libguile, libintl, and libltdl). Ensuring that the search path is correct would fix this problem, look at setting the LTDL_LIBRARY_PATH environment variable, perhaps? Anyway, I am convinced that this is a packaging bug. Peter -- Peter O'Gorman http://pogma.com
