[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mac OS X .dylib not working

From: Hans Aberg
Subject: Re: Mac OS X .dylib not working
Date: Thu, 4 Feb 2010 17:52:24 +0100

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
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/../
dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../
dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../
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.


reply via email to

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