I am installing Pyglet as a dependency for VisPy but am seeing the following error after installation
File "/Library/Python/2.7/site-packages/pyglet/lib.py", line 160, in load_library
raise ImportError('Library "%s" not found.' % names[0])
ImportError: Library "c" not found.
Digging through the source code, I realized that Pyglet is attempting to load the standard C library using the ctypes framework.
Further digging reveals the actual (un-swallowed) error:
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libc.dylib, 6): no suitable image found. Did find:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libc.dylib: mach-o, but wrong filetype
The issue, I think, is similar to this question where there is an architecture mismatch. The Python C binding framework 'ctypes' is attempting to load a .dylib with the wrong architecture.
Since I have set $LD_LIBRARY_PATH to
/Applications.../MacOSX10.10.sdk/usr/lib/
the loader is favoring this directory. However, if I try to load 'libc.dylib' from the standard location /usr/lib everything works perfectly.
The obvious potential problem is that the XCode version of 'libc' is for the 32-bit architecture but the /usr/lib is for the 64-bit architecture.
Not true!
Here is the output of file for both libraries:
XCode version
libc.dylib: Mach-O universal binary with 2 architectures
libc.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64
libc.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386
and the standard in /usr/lib
/usr/lib/libc.dylib: Mach-O universal binary with 2 architectures
/usr/lib/libc.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/usr/lib/libc.dylib (for architecture i386): Mach-O dynamically linked shared library i386
The only difference is that the XCode version is a "stub". Despite some googling, the difference is not entirely clear, though it appears that the difference between a "stub" dylib and a "non-stub" is what is causing the problem.
A bit more information about my setup:
/usr/bin/python : Python 2.7.10 and appears to be running as a 64-bit app
uname -a: Darwin x-10-104-106-204.uofm-secure.wireless.umn.edu 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64
My question is thus how does one properly link against the dylibs installed by XCode?
Thanks in advance for all ideas and suggestions.
