need help debugging wierd dlopen failure

[Frank Goenninger]

Jim,

loading a specific version of a shared library requires two things:

a.  Use absolute path to the library in the cffi lib spec
b.  Make sure the dependencies (see output of otool -L ) (the paths to the dependencies) are at the beginning of the paths set in the environment variable DYLD_LIBRARY_PATH. 

Best
    Frank

--
  Frank Gönninger
  DG1SBG
  Consequor Consulting AG
  

> Am 20.09.2016 um 16:46 schrieb Jim Newton <jimka.issy at gmail.com>:
> 
> Hi Frank, thanks for the information.  If you always use /usr/local/lib then what do you do when you need to run two different independent applications which have different requirements?
> 
>> On Tue, Sep 20, 2016 at 3:44 PM, Frank Goenninger <frgo at me.com> wrote:
>> Am 20.09.2016 um 15:32 schrieb Luís Oliveira <luismbo at gmail.com>:
>> >
>> > On Tue, Sep 20, 2016 at 10:53 AM, Jim Newton <jimka.issy at gmail.com> wrote:
>> >> CL-USER> (cffi::list-foreign-libraries)
>> >> (...
>> >> #<CFFI:FOREIGN-LIBRARY
>> >>   :LIBCAIRO #P"/usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.dylib" (truename=#P"/usr/local/Cellar/cairo/1.12.16_1/lib/libcairo.2.dylib")>)
>> >> CL-USER>
>> >>
>> >> However, when I attempt to load libgdk-x11-2.0.0.dylib it complains that it cannot find a particular symbol in /usr/local/lib/libcairo.dylib.  Why is it complaining about /usr/local/lib/libcairo.dylib?
>> >
>> > Most of those dylibs are symlinks and libgdk may depend on a name
>> > which exists in /usr/local/lib but not /usr/local/Cellar, maybe? ldd
>> > can tell you what a given dylib depends on.
>> 
>> As Jim is on macOS there is no ldd. The command to use is
>> 
>> otool -L /usr/local/lib//libcairo.dylib
>> 
>> Seeing that Jim uses homebrew to install Cairo it is worth mentioning that brew install … also generates (normally) an entry in /usr/local/lib . That is why I always stick to using /usr/local/lib/libxyz.dylib paths when I want to ensure a particular library to be loaded.
>> 
>> Best,
>>    Frank
>> 
>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20160921/19bb0f54/attachment.html>