Problem loading a dylib file through LOAD-FOREIGN-FUNCTION

[Robert P. Goldman]

Thanks for the advice.

The solution I found was to copy the foo.dylib files onto foo.0.dylib so that they would be loaded. That fixed the bug (which turns out to have nothing to do with CFFI).

The libraries came from the NuSMV model-checker (NuSMV.fbk.eu).

My conjecture is that the build script doesn't properly handle Apple's symbol table files. Probably it should simply not generate them, but I am not enough of an autoconf expert to fix that.

Best,
R



On Aug 26, 2013, at 2:15, Frank Goenninger <dg1sbg at googlemail.com> wrote:

> Ok, jumping in here.
> 
> The output says it all:
> 
> $ file /usr/local/lib/libsmvgrammar.dylib
> /usr/local/lib/libsmvgrammar.dylib: Mach-O universal binary with 1
> architecture: [x86_64: Mach-O 64-bit x86_64 dynamically linked shared
> library]
> 
> So, this *is* a shared library.
> 
> $ file /usr/local/lib/libsmvgrammar.0.dylib
> /usr/local/lib/libsmvgrammar.0.dylib: Mach-O universal binary with 1
> architecture: [x86_64: Mach-O 64-bit x86_64 dSYM companion file]
> 
> And this is *not*. It therefore should *not* have the .dylib ending - but
> .dsym. This is one error. The build process seems to be in error here.
> What does otool -L say on both files?
> There should be *no* reference to /usr/local/lib/libsmvgrammar.0.xxx in
> /usr/local/lib/libsmvgrammar.dylib.
> 
> To analyze further: did you get these libs from? (Sorry, didn't follow the
> whole thread).
> 
> Regards
>  Frank
> 
> 
> 
> Am 26.08.13 02:54 schrieb "Robert P. Goldman" unter <rpgoldman at sift.info>:
> 
>> Luís Oliveira wrote:
>>> On Sun, Aug 25, 2013 at 3:34 PM, Robert P. Goldman
>>> <rpgoldman at sift.info> wrote:
>>>> $ file /usr/local/lib/libsmvgrammar.0.dylib
>>>> /usr/local/lib/libsmvgrammar.0.dylib: Mach-O universal binary with 1
>>>> architecture: [x86_64: Mach-O 64-bit x86_64 dSYM companion file]
>>> 
>>> This description doesn't look right. The dylibs on my system look like
>>> this:
>>> 
>>> $ file libtest.dylib
>>> libtest.dylib: Mach-O 64-bit dynamically linked shared library x86_64
>>> 
>>> Perhaps the project you're compiling should be passing -dynamiclib to
>>> gcc but isn't?
>> 
>> Actually, I think what's wrong is that dlopen is goIng pear-shaped when
>> it tries to load the dSYM companion file.  This is a file that seems to
>> be ancillary to libsmvgrammar.dylib, which IS a dynamically linked shared
>> library:
>> 
>> $ file /usr/local/lib/libsmvgrammar.dylib
>> /usr/local/lib/libsmvgrammar.dylib: Mach-O universal binary with 1
>> architecture: [x86_64: Mach-O 64-bit x86_64 dynamically linked shared
>> library]
>> $ file /usr/local/lib/libsmvgrammar.0.dylib
>> /usr/local/lib/libsmvgrammar.0.dylib: Mach-O universal binary with 1
>> architecture: [x86_64: Mach-O 64-bit x86_64 dSYM companion file]
>> 
>> The main library file I am trying to load somehow references
>> libsmvgrammar.0.dylib, causing it to be loaded with dlopen and then I get
>> the error.  But I can't see why it would be trying to dlopen() what seems
>> like a symbol table.
> 
>