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.
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 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.
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 would like to know how you can support i386 and ppc architectures for programs at /bin.
I run for instance
bin $ file amber
I get
amber: setgid Mach-O universal binary with 2 architectures
amber (for architecture i386): Mach-O executable i386
amber (for architecture ppc): Mach-O executable ppc
How do programs support i386 and ppc in the source code?
In other words, which components can you remove, for instance, in /bin/amber if you remove the support of ppc -architecture?
It's called a Universal binary. In short, the executable contains both types of executable code. Apple has a published document describing how developers should build their applications to run on either platform.
The executable lipo can be used to remove either version of the executable from the file. If you want your executables to contain only one version, you can use lipo to achieve this.
Be aware that there is more than just ppc and i386, although these are the "safest" architectures to choose for a Universal binary. Read the manpage for arch; there you can see that a modern OSX binary is likely to contain any of ppc, ppc64, i386 or x86_64. There are many more listed, but they exist there for completeness.
It's called a fat binary.
There's a copy of the native code for both architectures in the binary. The binary format and the operating system have to support it, so it can know where to look in the file for the correct code.