Problem loading a dylib file through LOAD-FOREIGN-FUNCTION
I have been trying to load a dylib file I got from compiling the NuSMV model-checking program (nusmv.fbk.eu). I keep getting this error, which I am afraid I don't understand: Unable to load foreign library (LIBNUSMV.DYLIB-1090). Error opening shared object "libnusmv.dylib": dlopen(libnusmv.dylib, 10): Library not loaded: /usr/local/lib/libsmvgrammar.0.dylib Referenced from: /usr/local/lib/libnusmv.dylib Reason: no suitable image found. Did find: /usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype /usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype. If this had said "wrong architecture", I would have guessed that this was a 32bit/64bit mismatch. But "wrong filetype" seems to indicate a different error, and one that I haven't had any luck googling. At any rate, I have checked and I have x86_64 SBCL and x86_64 dylibs. Any suggestions would be very welcome. Thanks, R
On Sun, Aug 25, 2013 at 3:46 AM, Robert P. Goldman <rpgoldman@sift.info> wrote:
/usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype.
If this had said "wrong architecture", I would have guessed that this was a 32bit/64bit mismatch. But "wrong filetype" seems to indicate a different error, and one that I haven't had any luck googling. At any rate, I have checked and I have x86_64 SBCL and x86_64 dylibs.
I've never come across this either. What does the "file" command have to say about libsmvgrammar.0.dylib? Also, what happens when you try to foreign load that? Cheers, -- Luís Oliveira http://kerno.org/~luis/
Luís Oliveira wrote:
On Sun, Aug 25, 2013 at 3:46 AM, Robert P. Goldman <rpgoldman@sift.info> wrote:
/usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype.
If this had said "wrong architecture", I would have guessed that this was a 32bit/64bit mismatch. But "wrong filetype" seems to indicate a different error, and one that I haven't had any luck googling. At any rate, I have checked and I have x86_64 SBCL and x86_64 dylibs.
I've never come across this either. What does the "file" command have to say about libsmvgrammar.0.dylib? Also, what happens when you try to foreign load that?
Cheers,
I get the same error: Unable to load foreign library (LIBSMVGRAMMAR.0.DYLIB-1099). Error opening shared object "libsmvgrammar.0.dylib": dlopen(libsmvgrammar.0.dylib, 10): no suitable image found. Did find: /usr/local/lib/libsmvgrammar.0.dylib: mach-o, but wrong filetype. [Condition of type LOAD-FOREIGN-LIBRARY-ERROR] Here's some more information: $ otool -f /usr/local/lib/libsmvgrammar.0.dylib Fat headers fat_magic 0xcafebabe nfat_arch 1 architecture 0 cputype 16777223 cpusubtype 3 capabilities 0x0 offset 4096 size 38332 align 2^12 (4096) $ lipo -detailed_info /usr/local/lib/libsmvgrammar.0.dylib Fat header in: /usr/local/lib/libsmvgrammar.0.dylib fat_magic 0xcafebabe nfat_arch 1 architecture x86_64 cputype CPU_TYPE_X86_64 cpusubtype CPU_SUBTYPE_X86_64_ALL offset 4096 size 38332 align 2^12 (4096) $ 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] BTW. these results are from after I used lipo -create on the original file: I was concerned that the file might not be working because it was a thin file instead of a fat file. But "fattening" it seems to make no difference. I have seen a couple of mentions of this filetype error in google, but only in contexts where someone works around it -- in no place do I see a definition of what this error string is intended to mean (unlike the "wrong architecture" one), including on the Apple Developer list. I was able to load libaspell.dylib, so I don't think it's that my machine is hopelessly messed up. For that library I see, by contrast $ lipo -detailed_info libaspell.dylib Fat header in: libaspell.dylib fat_magic 0xcafebabe nfat_arch 4 architecture ppc cputype CPU_TYPE_POWERPC cpusubtype CPU_SUBTYPE_POWERPC_ALL offset 4096 size 1961296 align 2^12 (4096) architecture i386 cputype CPU_TYPE_I386 cpusubtype CPU_SUBTYPE_I386_ALL offset 1966080 size 1506276 align 2^12 (4096) architecture ppc64 cputype CPU_TYPE_POWERPC64 cpusubtype CPU_SUBTYPE_POWERPC_ALL offset 3473408 size 2058888 align 2^12 (4096) architecture x86_64 cputype CPU_TYPE_X86_64 cpusubtype CPU_SUBTYPE_X86_64_ALL offset 5533696 size 1714136 align 2^12 (4096) This seems to be a dlopen error, not something that's wrong with CFFI -- I was just hoping someone here would know. Cheers, r
On Sun, Aug 25, 2013 at 3:34 PM, Robert P. Goldman <rpgoldman@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? -- Luís Oliveira http://kerno.org/~luis/
Luís Oliveira wrote:
On Sun, Aug 25, 2013 at 3:34 PM, Robert P. Goldman <rpgoldman@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.
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@sift.info>:
Luís Oliveira wrote:
On Sun, Aug 25, 2013 at 3:34 PM, Robert P. Goldman <rpgoldman@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.
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@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@sift.info>:
Luís Oliveira wrote:
On Sun, Aug 25, 2013 at 3:34 PM, Robert P. Goldman <rpgoldman@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.
participants (3)
-
Frank Goenninger -
Luís Oliveira -
Robert P. Goldman