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
Related
Ok so I'm trying to compile my Awesomium go wrapper on my mac (everything works fine on linux). My problem is, when I try to compile I get
ld: warning: ignoring file /Library/Frameworks//Awesomium.framework/Awesomium, file was built for i386 which is not the architecture being linked (x86_64): /Library/Frameworks//Awesomium.framework/Awesomium
Undefined symbols for architecture x86_64:
Fine. But that raises a few questions. First, I didn't have the option to download a x86_64 version for Mac, it was "the mac version" no architecture. Second, I checked a few other libraries and it seems like nothing is built x86_64.
Now I thought maybe I could make a i386 version just for osx but it seems it's extremely difficult, some say impossible, to cross compile cgo.
What are my options?
I'm not sure if you're going to run into any other problems with the universal binary, but building an i386 go toolchain is fairly easy.
http://golang.org/doc/install/source
You can then set the GOHOSTARCH and GOARCH environment variables, e.g.
GOHOSTARCH=386 GOARCH=386 ./all.bash
What is involved in compiling 32-bit Intel OS X binaries on a 64-bit command-line environment? Is it as simple as adding a -m32 flag? I'm not using Xcode, but could use it to install libraries that gcc could use, if needed. Thanks for your advice.
If you're compiling on a Macintosh computer using Apple's implementation of GCC, one of the extra options you can pass along is the "-arch" parameter.
The man page says this:
-arch arch
Compile for the specified target architecture arch.
The allowable values are i386, x86_64, ppc and ppc64.
Multiple options work, and direct the compiler to produce "universal"
binaries including object code for each architecture specified with -arch.
This option only works if assembler and libraries are available
for each architecture specified. (APPLE ONLY)
This may be a very silly question, but I'm new to developing on Macs and am having a hard time with the universal binaries.
I've got an application that I'm compiling in QT Creator, which according to lipo is producing i386 architecture outputs. As I understand it, that means it is producing Mac OS X 32 bit outputs.
The application depends on two external libraries. One of these libraries I'm compiling by calling ./config first, and then make. ./config states that it is "Configured for darwin-i386-cc". However, after running make, and calling lipo on the result, the architecture is reported as x86_64.
Similarly, I have another external library. That one has no configure script, and I compile it simply by calling make. The output from this one too is x86_64.
How can I compile these two external libraries so that they produce something compatible with my application's i386 output? Better yet, how can I compile these two external libraries to produce universal libraries so I can produce a universal binary from my application that works on both 32 and 64 bit?
Also, based on the current state of the Mac world, are there any other platforms that I should be expected to target to create a proper, user-friendly Mac OS X universal binary?
Finally got it working.
In order to control the architecture of the target, I manually went in and edited the Makefiles.
For one of them, I added to the end of the line that starts with CFLAGS: -arch i386 -arch x86_64 -arch ppc
This produced a universal binary.
For the other, when I did the same thing, the compile would error out. I had to cycle through and only put one arch at a time, and then after I produced all three, I called lipo on them with the -create flag to create a universal binary.
for ./configure, you can use this:
./configure CFLAGS="-arch i386 -arch x86_64" CXXFLAGS="-arch i386 -arch x86_64" LDFLAGS="-arch i386 -arch x86_64" --disable-dependency-tracking
--disable-dependency-tracking is important or gcc/g++ will refuse to compile code.
I can't answer the main part of your question, because I always use Xcode rather than make. But as for that last part, if you support OS versions earlier than 10.6, you may need to compile for PowerPC (arch. code "ppc") as well.
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..).
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.