I have some dylibs to load from python with ctypes. I can load libbass.dylib without problem, but I can't load the self-compiled libmp3lame.dylib. Here is the error I get.
OSError: dlopen(libmp3lame.dylib, 6):
no suitable image found. Did find:
libmp3lame.dylib: mach-o, but wrong
architecture
Then, I inspect the file type of those libs. Here is the result of libbass.dylib:
libbass.dylib: Mach-O universal binary with 2 architectures
libbass.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libbass.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc
And here is the self-compiled one:
libmp3lame.dylib: Mach-O 64-bit dynamically linked shared library x86_64
I did compile the lame library with the install instructions:
./configure
make
make install
I'm new to mac system, here comes the problem: how to build the libmp3lame.dylib so that it supports different architecture I want?
Thanks.
Just run:
CFLAGS="-arch i386 -arch x86_64 -arch pcc" ./configure
For further information, see http://developer.apple.com/library/mac/#technotes/tn2005/tn2137.html
Related
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.
I have a Fortran 90 program which uses lapack subroutines, and is successfully running on my Ubuntu system. Now I want to run it on Mac (OS X Version 10.11.4). I am using gfortran compiler as a part of gcc, installed from homebrew repositories, and lapack library, installed in /usr/local/lib/.
When I try to compile my code, I get the following error:
gfortran my_prog.f90 -L/usr/local/lib/ -llapack
Undefined symbols for architecture x86_64:
"_daxpy_", referenced from:
_zggbal_ in liblapack.a(zggbal.o)
...
"_ztrmv_", referenced from:
_zlarft_ in liblapack.a(zlarft.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
After some google search I understood that the problem is because the linking. When I compile it like this, everything works well:
gfortran my_prog.f90 -llapack
Also when llapack from framework accelerate is used, the compiler doesn't complain.
gfortran my_prog.f90 -framework accelerate
The libraries are of x86-64 architecture:
lipo -info *.a
input file libfftw3.a is not a fat file
input file liblapack.a is not a fat file
Non-fat file: libfftw3.a is architecture: x86_64
Non-fat file: liblapack.a is architecture: x86_64
LAPACK is not the only one which gives me an error, later the same problem appears with FFTW3. Could you please give me a hint to the solution to this problem?
FFTW is not part of the accelerate framework. If you want to use it, you need to add -lfftw3 to the compile options as well.
If the libraries are not in the default LIBRARY_PATH, you might need to specify -L/path/to/fftw/libs as well. The same holds for the include path if you are using its modules -I/path/to/fftw/includes.
Note that the vDSP part of the library also provides FFT implementations. You might not need FFTW at all.
I was attempting to install XML::LibXSLT via CPAN, this seemed to work fine, until I attempted to load Google Chrome, or Microsoft Office. I am getting an error launching these programs with the following errors:
Dyld Error Message:
Library not loaded: /usr/lib/libxslt.1.dylib
Referenced from: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks
/DictionaryServices.framework/Versions/A/DictionaryServices
Reason: no suitable image found. Did find:
/usr/lib/libxslt.1.dylib: mach-o, but wrong architecture
/usr/lib/libxslt.1.dylib: mach-o, but wrong architecture
Obviously the problem is the new dylibs that XSLT installed, but these all seem to be X86_64 so I shouldn't be seeing any issues with this, I am running Mac OS X 10.6.8.
When running file /opt/local/lib/libxslt.dylib
I get:
/opt/local/lib/libxslt.dylib: Mach-O 64-bit dynamically linked shared library x86_64
as is the same with the libxslt.1.dylib.
Is there a way to solve this issue, and reinstate the original files that must have been replaced?
Edit: If were to get a copy of these Libraries from another Mac 10.6.8 64 bit and replace my apparantly confused ones with these, would this at least solve the issue of them being all mixed up.
Also running
[/usr/lib]$ ls | grep libxslt gives me :
libxslt 2.dylib
libxslt-plugins
libxslt.1.dylib
libxslt.a
libxslt.dylib
libxslt.la
libxslt.pc
Did you install into or otherwise replace the original Apple-supplied libraries in /usr/lib? You should never do that. Otherwise, you'll likely break other parts of OS X that depend on those libraries. You should restore the original libraries from a backup or reinstall OS X. If you want newer versions, you should install them elsewhere, like in /usr/local/lib. Or better yet you should be using a third-party package manager, like Homebrew or MacPorts; in fact, you appear to be using MacPorts, judging from the /opt/local/lib path. Use that and don't alter system files in /usr (other than /usr/local) or /System/Library.
This may be relevant: How to compile universal binaries on Mac OS X.
I ran into this same issue where I had re-compiled libxslt and libxml to support python bindings, then started getting the /usr/lib/libxslt.1.dylib: mach-o, but wrong architecture error and an immediate crash when starting some apps (Specifically Synergy, which is a 32-bit/i386 app)
I solved this by recompiling libxml2 and libxslt using these configure options:
./configure CFLAGS="-arch i386 -arch x86_64" \
CXXFLAGS="-arch i386 -arch x86_64" \
LDFLAGS="-arch i386 -arch x86_64" \
--disable-dependency-tracking
Now libxml2 and libxslt libraries are properly showing as universal binaries:
$ file /usr/local/lib/libxslt.1.dylib /usr/local/lib/libxslt.1.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libxslt.1.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libxslt.1.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
$ file /usr/local/lib/libxml2.2.dylib
/usr/local/lib/libxml2.2.dylib: Mach-O universal binary with 2 architectures
/usr/local/lib/libxml2.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/local/lib/libxml2.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
I try to use the library libstk.a (from The Synthesis ToolKit in C++ (STK))in a XCode 4.5.1 application project to build for Standard(32/64 bit Intel) architectures.
I just drop the file libstk.a and stk.h into my project.
First I made the library of stk-4.4.4 following the instructions given in the doc of stk (./configure with --with-core and --enable-debug) and then make in the src directory. It gives the libstk.a file without errors.
In the xcode project, no syntax error, but link errors : undefined symbol for architecture x86_64 for different methods (maybe all) + the same for i386
It looks like libstk.a was not build for i386 or x86_64.
I used command lines to make the library and i am not familiar with this. How can I ensure that the library will be build for i386 and i86_64 archs ? Do I have to do something different to include the library in my project than just drop it in the files list ? I need help !
Use -arch i386 or -arch x86_64 gcc option..
I have successfully built and installed gcc 4.6.1 on my OS X box, but I can't seem to get it to create a fat/universal libstdc++ library for me. How do I make it do that?
The default /usr/lib/libstdc++.6.dylib supports the following architectures:
[host:~] nsteiner% file /usr/lib/libstdc++.6.dylib
/usr/lib/libstdc++.6.dylib: Mach-O universal binary with 3 architectures
/usr/lib/libstdc++.6.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/lib/libstdc++.6.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc
/usr/lib/libstdc++.6.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
I would like for gcc to give me a /usr/local/lib/libstdc++.6.dylib for those same architectures, but my attempts to configure with --enable-multilib or --with-multilib-list=i386,ppc,x86_64 or --enable-targets=all were clearly misguided. Neither configure nor make generate errors, but all that gets generated is this:
[host:~] nsteiner% file /usr/local/lib/libstdc++.6.dylib
/usr/local/lib/libstdc++.6.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Only Apple's GCC 4.2.1 still supports fat binaries. You'll have to take additional manual steps (or provide damn good wrapper scripts) to compile all sources twice, and run lipo on the resulting binaries.