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..).
Related
I am building the shared library which can be used for my python program using command.
go build -o program.so -buildmode=c-shared myprogram/program.go
However, it seems that for me to use the shared library on another machine, I have to include all the source code. Otherwise, I would get OSError: invalid ELF header.
Is using the shared library without source code possible?
Library is a binary artifact and will only work on same architecture as it was built for. OSError: invalid ELF header means the library is for different architecture (e.g. library built on x86_64 Linux won't load on arm Linux, x86_64 MacOS X and so on).
Use without source code is perfectly possible if you build library binaries for all architectures (CPU and OS) where your users intend to use it.
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 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 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.
Is this legal? I'm getting an error "Can't find <lib>.framework/Versions/4/<lib>" from the linker. In this case, <lib> is 'QtGui' that has been built as an i386 framework (not universal), but another (third party) lib I'm linking to (that uses QtGui) is universal.
I'm thinking everything has to be built universal or not...
You can link a non-universal framework (say i386 only) with a universal framework (say with i386 and x86_64) to make an i386 binary.
Of course you can't make an x86_64 binary in this case.
Note that if your Mac has a 64 bit CPU, the linker defaults to mae an x86_64 binary. So the linker will complain if any of your library does not have the x86_64 part. If you want to create an i386 binary, you need to specify that explicitly on the command line.
Roger.
Turns out my issue actually stems from bad embedded paths in the external libraries that have to be reset (which I didn't think would affect links, but it does).
The universal build issue was a suspected culprit, but no.
Thanks,
rickb