Re: Mac OS X .dylib not working
On 4 Feb 2010, at 16:34, Peter O'Gorman wrote: $ 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? Sorry, I should have answered this one: the variable isn't set, and exporting it to say LTDL_LIBRARY_PATH=/Applications/LilyPond.app/Contents/Resources/lib before starting 'lilypond' does not change the behavior. Hans
Re: Mac OS X .dylib not working
On 4 Feb 2010, at 16:34, Peter O'Gorman wrote: 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. The only computers that can't run 10.4 are G3 and they are really to slow. At least the one I installed it on. !0.5 runs fine also on a G4 350 Ghz I tried it on. 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? None. There is some mentioning about c99 and make about .c, .f and .o files, but really no requirements. You can use those for portability reasons. Or at least that is what they say one the UNIX standardization list. $ 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? Does what flags does libtool use when compiling dynamic libraries? One can compile with name lookup table and direct jump table. The former, it seems would not break if version differ, if they contain the same function. Anyway, I am convinced that this is a packaging bug. They will probably have to do something to make sure their own libraries are called - that's their bug. Hans
Re: Mac OS X .dylib not working
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
Re: Mac OS X .dylib not working
On Thu, Feb 04, 2010 at 01:40:07PM +0100, Hans Aberg wrote: > On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote: > >> Under OS-X (Leopard and later), the 'dtruss' program can be used to >> see what is really going on. > > While at it, I found another problem involving libltdl.7.dylib, > guile-1.8.7 and lilypond 2.13.7: > > When upgrading guile using libtool-2.2.6b, lilypond broke, the one which > is in an Application distribution: > /Applications/LilyPond.app/Contents/Resources/bin/guile > It has its own > /Applications/LilyPond.app/Contents/Resources/lib/libltdl.7.dylib > > However, dtruss shows that segmentation fault is caused when calling > /usr/local/lib/libltdl.7.dylib > > When I move this to another name, then lilypond works, but dtruss now > shows that it calls > /usr/lib/libltdl.7.dylib Sorry, I missed most of this thread as I was travelling. What does otool -L /Applications/LilyPond.app/Contents/Resources/bin/guile say? Which libltdl.7.dylib does it list? If you run lilypond with DYLD_PRINT_LIBRARIES=1 set in the environment does more than one copy of libltdl.7.dylib get loaded? This sounds like a packaging bug to me though, you can probably fix it with use of install_name_tool(1). As for your earlier questions about .so and .dylib - On Mac OS X 10.0 and earlier, there was no way to load MH_DYLIB type files (usually .dylib extensions) at runtime. API was introduced to allow this in 10.1, and dlopen() was added in 10.3, rewritten in 10.4 and dlclose() actually removes the image in 10.5, prior to that only files of MH_BUNDLE type could be unloaded. 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. So, long story short, ltld looks for ".so" because that is the extension used for loadable modules. Guile wants to use its loadable modules as input to ld, this is not portable to ancient Mac OS X, nor ancient Net BSD, and possibly other systems, however it seems unlikly to be a major issue. I think that covers most of the thread, but I admit to now reading all of it. Peter -- Peter O'Gorman http://pogma.com
Re: Mac OS X .dylib not working
On 4 Feb 2010, at 14:49, Peter O'Gorman wrote: What does otool -L /Applications/LilyPond.app/Contents/Resources/bin/guile say? Which libltdl.7.dylib does it list? See below. They differ: libltdl.7.dylib current versions 10.0.0 and 10.1.0. If you run lilypond with DYLD_PRINT_LIBRARIES=1 set in the environment does more than one copy of libltdl.7.dylib get loaded? It just tries to load the one in /usr/local/lib/, which causes segmentation fault. This sounds like a packaging bug to me though, ... Part if it, at least. There is no point searching for incompatible libraries. ...you can probably fix it with use of install_name_tool(1). I can pass it on - I'm not a LilyPond developer. As for your earlier questions about .so and .dylib - On Mac OS X 10.0 and earlier, there was no way to load MH_DYLIB type files (usually .dylib extensions) at runtime. API was introduced to allow this in 10.1, and dlopen() was added in 10.3, rewritten in 10.4 and dlclose() actually removes the image in 10.5, prior to that only files of MH_BUNDLE type could be unloaded. 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. So just add .dylib to the list of searches. 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. Guile wants to use its loadable modules as input to ld, this is not portable to ancient Mac OS X, nor ancient Net BSD, and possibly other systems, however it seems unlikly to be a major issue. I think that covers most of the thread, but I admit to now reading all of it. If it can't load .dylib files, which now is the normal use, that is a bit confusing. Hans # otool -L /Applications/LilyPond.app/Contents/Resources/bin/guile /Applications/LilyPond.app/Contents/Resources/bin/guile: @executable_path/../lib//libguile.17.dylib (compatibility version 21.0.0, current version 21.1.0) @executable_path/../lib//libintl.8.dylib (compatibility version 9.0.0, current version 9.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3) @executable_path/../lib//libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) @executable_path/../lib//libltdl.7.dylib (compatibility version 10.0.0, current version 10.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) # otool -L /usr/local/bin/guile /usr/local/bin/guile: /usr/local/lib/libguile.17.dylib (compatibility version 21.0.0, current version 21.1.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/local/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 9.0.0) /usr/local/lib/libltdl.7.dylib (compatibility version 10.0.0, current version 10.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) $ lilypond empty.ly dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/lilypond dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libintl.8.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libguile.17.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libgmp.3.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libpangoft2-1.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libpango-1.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libfreetype.6.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libfontconfig.1.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libgobject-2.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libgmodule-2.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libglib-2.0.0.dylib dyld: loaded: /usr/lib/libstdc++.6.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/libmx.A.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/ Versions/A/CoreFoundation d
Re: Mac OS X .dylib not working
On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote: Under OS-X (Leopard and later), the 'dtruss' program can be used to see what is really going on. While at it, I found another problem involving libltdl.7.dylib, guile-1.8.7 and lilypond 2.13.7: When upgrading guile using libtool-2.2.6b, lilypond broke, the one which is in an Application distribution: /Applications/LilyPond.app/Contents/Resources/bin/guile It has its own /Applications/LilyPond.app/Contents/Resources/lib/libltdl.7.dylib However, dtruss shows that segmentation fault is caused when calling /usr/local/lib/libltdl.7.dylib When I move this to another name, then lilypond works, but dtruss now shows that it calls /usr/lib/libltdl.7.dylib So it seems lilypond never calls its own libltdl.7.dylib. The problem here, though, is the combination of incompatible versions of libltdl.7.dylib in combination with a library search path. If they really are incompatible, there seems to be no point in having a searchpath. I think that gcc on Mac OS X makes hardcoded full paths for libraries. So libtool would then implement its own library search paths. Also, it seems having no problem open .dylib files here. Hans
