Python Ctypes Not Loading Dynamic Library on MAC Os X

Python ctypes not loading dynamic library on Mac OS X

Nope. As the error message says, there's an architecture mismatch between your python and librepeater.dylib file. Use file to check what the architecture of librepeater.dylib is; your python is going to be built using one of the ones not listed.

Where does ctypes LoadLibrary() search for libs on OS X?

On OSX (as on (almost) any Nix), CTypes uses dlopen to open an .so (.dylib). According to [Apple.Developer]: DLOPEN(3) (or man dlopen) (emphasis is mine):

When path doesn't contain a slash character (i.e. it is just a leaf name), dlopen() searches the following until it finds a compatible Mach-O file: $LD_LIBRARY_PATH, $DYLD_LIBRARY_PATH, current working directory, $DYLD_FALLBACK_LIBRARY_PATH.

So, you could launch your script like (where %s mark placeholders):

LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:%PATH_TO_YOUR_LIB_DIR% %COMMAND_LAUNCHING_SCRIPT% 

Problem loading dylib libraries in python with macOS

libneurongpu is calling a sub library libcurand via an @rpath and not finding it wherever it’s looking. Try an otool -l /usr/local/lib/libneurongpu.0.dylib to see the @rpath.
Then you may wish to adjust the library to call the sub library from the correct location.

There are two options.

1.
Remove the @rpath in the library path.
install_name_tool -change @rpath/libcurand.10.dylib
libcurand.10.dylib /usr/local/lib/libneurongpu.0.dylib

This will search the same directory as the calling library.

2.
Set the @rpath (or add another) to the correct directory.
install_name_tool -add_rpath /usr/local/bin /usr/local/lib/libneurongpu.0.dylib

Mac OS X Lion Python Ctype CDLL error lib.so.6 : image not found

Shared libraries on Mac OS X tend to have the extension .dylib instead of .so. In this case, /usr/lib/libc.dylib is what you want so load libc.dylib.

Mac OS X Python ctypes cdll error: image not found

Shared libraries (e.g., Windows DLLs) are like compiled binary executables: they only run on the platform for which they were compiled. ctypes can and will not translate between the various binary formats and calling conventions on different platforms. You will have to recompile the DLL as a Mac OS shared library (.dylib, I think).

Ctypes symbol not found for dynamic library in OSX

The problem is most likely the fact that you are using C++, and hence the function name will be mangled and use C++ calling conventions. If you declare the function with extern "C" then it should be exported in such a way as to callable from C code (and from Python's CTypes module).

`cdll.LoadLibrary(my.so)` throws no suitable image found. but architectures match, and both for 64 bit. Why?

MacOS doesn’t use the ELF shared object format, so it can’t be loaded by the MacOS dynamic linker. As it is based on the Mach microkernel, it continues to use the Mach-O binary format, and its shared libraries generally use the file extension .dylib.

In general, even if the architectures match and they both use ELF, you can’t use executable binaries/shared objects across different Operating Systems.



Related Topics



Leave a reply



Submit