Re: Mac OS X .dylib not working

[Hans Aberg <haberg@math.su.se>]

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