I would like to build an app with a universal binary containing: ppc, i386 and x86-64. The problem I have is that on 10.5.8 it tries to launch the x86-64 version and fails.
Is there some configuration that will make 10.5.8 launch with the i386 code?
See this SO question that suggests to configure through Info.plist.
I'm not aware of a method in the OS to target one version of the binary over another. I do know you can use lipo to remove the x86_64 version of the binary, which will cause the OS to run the i386 version, but I do not think it is what you want.
All that being said it would be my recommendation to debug the cause of the x86_64 crash, or only build the i386 version of the binary until you are in a place to debug it.
Related
I would like to assemble Aarch64 armv8 Assembly on my mac and eventually run it with qemu and maybe on a real device like a raspberry pi 2 or 4 later on. I don't know how to assemble the code I'm going to write, gcc, llvm-gcc and clang don't seem to support the -arch=armv8 flag or anything similar. So I can't build for the targeted architecture, how could I achieve this?
I'm running mac os 10.14.5. I wouldn't mind finding a solution that works on a recent ubuntu version either since I have a VM for linux development.
The clang version that ships with Xcode supports -arch arm64. (Or armv7 for 32bit.)
Note that if you want to use any libraries though, they'll have to be arm64 as well. If you want, you can invoke the iOS toolchain with xcrun -sdk iphoneos clang -arch arm64 [...], but then you'll also have to pull the libraries you want off of some IPSW and stuff them into qemu.
Also note that the above will give you a Mach-O binary. For your Raspberry Pi, you'll probably want an ELF, and you'll probably want gcc rather than clang. You should be able to build both gcc and GNU binutils from source with --target as either aarch64-linux-gnu or aarch64-none-elf, depending on your goals. Yet another note: since macOS silently aliases gcc to clang and many tools depend on that, you'll probably also want to build this toolchain with something like --program-prefix=aarch64-.
I'm using Xcode 3.2.3 on Mac OS X 10.6.6 on a Mac Pro to build revision 5fd480ef577f of GrowlTunes from the growl-development repository.
With a clean build from a virgin checkout, this is what I get:
% gdb build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:41:34 UTC 2010)
[blah blah blah]
This GDB was configured as "--host=x86_64-apple-darwin --target=powerpc-apple-darwin"...Reading symbols for shared libraries ......... done
(gdb) run
Starting program: /Volumes/RAM Disk/growl-development/Extras/GrowlTunes/build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
Don't know how to run. Try "help target".
When I try it in Xcode, it apparently does some internal test that fails, because it doesn't even list GDB as an option. Since there are no other debuggers (in this version of Xcode) for Cocoa applications, the pop-up menus related to debugging in the target Info window are empty, and attempting to run the app does nothing—the Run button switches back to being the Run button immediately.
The target is built for 32-bit PowerPC and 64-bit Intel:
% file build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes: Mach-O universal binary with 2 architectures
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture ppc7400): Mach-O executable ppc
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture x86_64): Mach-O 64-bit executable x86_64
I can run it directly, either from the terminal or from Finder, but that doesn't help me step-by-step debug.
This isn't a cross compilation scenario; I mean to run the 64-bit Intel architecture, which is my machine's native architecture, not the PowerPC architecture.
I'm guessing this is some build misconfiguration somewhere in the project, but I've no clue what or where. Any suggestions?
Workaround from a contact of mine:
gdb -arch x86_64 build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
I'd still appreciate a solution that would enable me to run/debug the app in Xcode.
Switching the order of the architectures in the relevant build setting fixed the problem both in gdb and in Xcode. This is a lame solution, and I'd still welcome a better one, but at least it works.
At gdb prompt, try 'set arch x86_64' or 'set arch i386:x86-64' (without quotes of course; I am a total newbie with gdb, I am lurking for solutions for other problems)
I'm trying to compile only for 32bit and 64bit. No matter what I choose in Xcode, I can either compile for 64bit or for 32bit, 64bit and ppc. I don't want ppc at all. Anyone has any idea how to compile for 32 & 64bit only?
Thanks!
In the Architectures setting for the project just set it explicitly to i386 and x86_64 rather than using the preset options.
To compile only for i386 and x86_64 (i.e. Intel) and not PPC, do the following:
Go to Project|Edit Project Settings
Select Build tab
In Architectures, do
not select any of the standard given
options such as Standard (32/64-bit
Universal) as these will always
throw in ppc. Select Other... and
add i386 and x86_64 manually.
In Valid Architectures, make it the same as Architectures (i.e. i386 and x86_64).
Compile. Test with lipo command in shell. (lipo -info test.app/Contents/MacOS/test) It should only say x86_64 i386 for architectures in file.
If that's not the case, then:
Go to Project|Edit Active Target "your app name" and do the same changes you did above, adding i386 and x86_64 manually.
Compile and test with lipo. It should say it's x86_64 i386 only.
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
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.