I have a problem with the important file libiconv.2.dylib. When I want to start some applications (like macvim, etc.) i get this error:
dyld: Library not loaded: /usr/lib/libiconv.2.dylib
Referenced from: /Applications/MacVim.app/Contents/MacOS/Vim
Reason: no suitable image found. Did find:
/usr/lib/libiconv.2.dylib: mach-o, but wrong architecture
/usr/lib/libiconv.2.dylib: mach-o, but wrong architecture
Trace/BPT trap
Is there any way to restore (no time machine available) or recompile this library for Mac (10.6)?
You appear to have a mismatch between architectures. The system library libiconv should be a universal file that contains all necessary archs; on OS X 10.6, Apple ships it with three.
$ file /usr/lib/libiconv.2.dylib
/usr/lib/libiconv.2.dylib: Mach-O universal binary with 3 architectures
/usr/lib/libiconv.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
/usr/lib/libiconv.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/lib/libiconv.2.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Try something similar for the MacVim.app executable:
$ file /Applications/MacVim.app/Contents/MacOS/Vim
There needs to be at least one common architecture and the app needs to be running in one of those common archs. Make sure you have a current version of the app. If the libiconv does not have all of those architectures, your system installation of OS X 10.6 is faulty. Perhaps you tried to install something into /usr/lib? Don't do that. If so, you may need to carefully reinstall OS X 10.6.
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 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 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.
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
I'm actually developping an application for iPhone and I need to use a library, initially dedicated to a Linux environment. Since I'm using a Mac (with Snow Leopard and Intel Core Duo), I guess it's possible to use this library in my app.
My library has 3 files: a file .h, a file .a and a file .so (both .a and .so are in /Developer/usr/lib). In addition I have included the .h i nmy code and I've added the .a in XCode has a framework (and it works because XCode find the .so compiling).
For your info when I use the command "file" for the file .so, I have:
ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
When I compile for the Xcode Simulator, I have a warning and an error.
The warning is:
In /Developer/usr/lib/mylib.so, file was built for unsupported
file format which is not the architecture being linked (i386)
The error is:
"_mylib_fct", referenced from:
-[MyAppAppDelegate applicationDidBecomeActive:] in
MyAppAppDelegate.o Symbol(s) not found Collect2: ld returned 1
exit status
When I compile for the Device 3.0 with architecture arm6, I also have the same error, but the warning is quite different:
ln /Users/Pablo/MyApp/mylib.a file is not of required architecture
I try to solve this and make the app working with this lib since days, and I don't understand why the compiler is complaining... is it a 32/64 bits issues? How can I deal with that?
Mac OS X is not binary compatible with Linux. It cannot load ELF images, nor does it share the same ABI.
It can only load MACH images, e.g.:
file /usr/lib/libcrypto.dylib
[..]
/usr/lib/libcrypto.dylib (for architecture i386): Mach-O dynamically linked shared library i386
Read the dlopen man page for details.
AFAIK If Mac OS is not binary compatible to the specific Linux version, the library should not be usable in your projects.
Also you need two versions, one for the simulator (i386) and one for the device (arm..).