bug-libtool
[Top][All Lists]
Advanced

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

Re: Mac OS X .dylib not working


From: Peter O'Gorman
Subject: Re: Mac OS X .dylib not working
Date: Thu, 4 Feb 2010 09:34:45 -0600
User-agent: Mutt/1.5.19 (2009-01-05)

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




reply via email to

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