Xcode & 64 bit & 32 bit Question - xcode

I have a 32bit iMac that I am writing an iPhone app in Xcode with, and I was wondering if I saved my project to a flash drive and dropped it on my MacBookPro which is 64 bit and continued to code the iPhone project on my laptop in Xcode would this cause a problem? I don't see how it would since the target is not for either of those computers, but I thought I would ask since I would like to work on the project when I am not always around my iMac. Are there any gottcha's with doing this that I should look out for?
Thanks,
I00I

No, this works fine. The compilers take source and compile to a particular target architecture; this is specified by the "-arch" flag to GCC. The executable produced is independent of the architecture that produces it. A compiler is a machine that takes input and produces output. It just takes your source and produces the output for the architecture you specify, no matter what the architecture on which the compiler is running.

Related

Random occurrences of Choose a destination with a supported architecture in order to run on this system

I have problems with running OSX applications with XCode. Sometimes (about 30% of the time) the application doesn't start and "XCode cannot run using the selected / Choose a destination with a supported architecture in order to run on this system." message is displayed instead.
This is NOT a duplicate of other questions, because this is not a problem with a project file (in such case the app would never run, and in my case the behaviour is random - sometimes it starts, sometimes not). This only happens with OSX applications.
XCode 5.0.2 (5A3005), OSX 10.9.3, but I had this problem since the first version of XCode 5 on both OSX 10.8 and 10.9.
Have you ever encountered similar issue?
Go ahead and attempt to check these settings: changing architecture settings. I have a feeling that sometimes your running on the 32 bit sim and sometimes the 64 bit sim so your running into the issue below.
Here's another link referencing how to change the standard Architecture for OSX: Changing OSX Architecture and ensure you're no longer set to be using gcc and only using LLVM: Other adjustments to bundle plist

MacOSX - Deploying 32 bit or 64 bit or Universal Binaries?

We have a C++ / Objective C based app.
We use LLVM-GVC compiler to compile our code.
Currently we build 32-bit binaries and deploy them on our customer's machines.
We support SnowLeopard, Lion, Mountain Lion and Mavericks.
I'm aware that all these are 64 bit OS. They can run 32 bit binaries fine.
But i want to know, going forward , is it a better idea to deploy 64bit binaries of my app?
I can compile our code base and build 64 bit binaries, but i will have to link against 3rd party 64bit libraries etc.
I think its do-able.
My question is what are the advantages of deploying 64 bit binaries, provided that 32binaries still work on these OS's?
Also what bout Universal Binary? Do you guys think building a Universal Binary would be a better option? If yes, why?
I'd appreciate any thoughts/suggestions.
If your binaries are standalone apps, as in they're not plugins or dylibs for other programs, then there's nothing wrong with using 32-bit binaries. You're in good company; if you look at Google's Chrome browser, that also uses 32-bit binaries.
The advantage of 64-bit is that you can address more memory, if required and I think there are a few assembler instructions that are faster with 64-bit instructions, but overall, if it works for you, I don't believe it's an issue.
If you find yourself creating a dylib that must work with both 32 and 64 bit applications, that would be a reason for creating a Universal Binary, to save having to create one of each and work out which you need at runtime; with a Universal Binary OSX will take care of that for you.

What is the "Illegal Instruction: 4" error and why does "-mmacosx-version-min=10.x" fix it?

I get Illegal Instruction: 4 errors with binaries compiled with GCC 4.7.2 under Mac OS X 10.8.2 ("Mountain Lion"), when those binaries are run under Mac OS X 10.7.x ("Lion") and earlier versions. The binaries work properly under Mac OS X 10.8.x.
I added -mmacosx-version-min=10.5 to my compile flags and this seems to help resolve the issue for 10.5.x, 10.6.x and 10.7.x clients, whatever that issue is.
Which gets to my question(s):
What is the Illegal Instruction: 4 error?
Why does -mmacosx-version-min=10.x fix this specific error on 10.x and greater clients?
I'd like to apply this fix to my makefiles, but would like to know what it is doing before I pull the trigger. (Will I have larger binaries? Do I still have 64-bit binaries? Are there gotchas with this approach I should know about? Unintended side-effects? Etc.)
From the Apple Developer Forum (account required):
"The compiler and linker are capable of using features and performing optimizations that do not work on older OS versions. -mmacosx-version-min tells the tools what OS versions you need to work with, so the tools can disable optimizations that won't run on those OS versions. If you need to run on older OS versions then you must use this flag.
"The downside to -mmacosx-version-min is that the app's performance may be worse on newer OS versions then it could have been if it did not need to be backwards-compatible. In most cases the differences are small."
The "illegal instruction" message is simply telling you that your binaries contain instructions the version of the OS that you are attempting to run them under does not understand. I can't give you the precise meaning of 4 but I expect that is internal to Apple.
Otherwise take a look at these... they are a little old, but probably tell you what you need to know
How does 64 bit code work on OS-X 10.5?
what does macosx-version-min imply?
I'm consciously writing this answer to an old question with this in mind, because the other answers didn't help me.
I got the Illegal Instruction: 4 while running the binary on the same system I had compiled it on, so -mmacosx-version-min didn't help.
I was using gcc in Code Blocks 16 on Mac OS X 10.11.
However, turning off all of Code Blocks' compiler flags for optimization worked. So look at all the flags Code Blocks set (right-click on the Project -> "Build Properties") and turn off all the flags you are sure you don't need, especially -s and the -Oflags for optimization. That did it for me.
I found my issue was an improper
if (leaf = NULL) {...}
where it should have been
if (leaf == NULL){...}
Check those compiler warnings!
I got this error when attempting to build with Xcode 10. It appears to be a bug in the Swift compiler. Building with Whole Module Optimization on, resolves the issue: https://forums.swift.org/t/illegal-instruction-4-when-trying-to-compile-project/16118
This is not an ideal solution, I will continue to use Xcode 9.4.1 until this issue is resolved.
In my case, I got this while overloading
ostream & operator << (ostream &out, const MyClass &obj)
and forgot to return out. In other systems this just generates a warning, but on macos it also generated an error (although it seems to print correctly).
The error was resolved by adding the correct return value. In my case, adding the -mmacosx-version-min flag had no effect.
I recently got this error. I had compiled the binary with -O3. Google told me that this means "illegal opcode", which seemed fishy to me. I then turned off all optimizations and reran. Now the error transformed to a segfault. Hence by setting -g and running valgrind I tracked the source down and fixed it. Reenabling all optimizations showed no further appearances of illegal instruction 4.
Apparently, optimizing wrong code can yield weird results.

Error building 32-bit OS X app?

I'm working on my first Mac OS X app. My project was set-up with XCode defaults and I haven't touched any Build Settings. When building for Mac 64-bit, the app runs fine. However, when building for Mac 32-bit, I get a seemingly arbitrary error that says:
Semantic issue: Synthesized property 'myProperty' must either be named the same as a compatible ivar or must explicitly name an ivar.
What kind of things can I check for?
It sounds like you have found the error but I think I can answer your question just in case someone else later finds it.
Apple has made a lot of changes in the 64 bit Objective-C runtime which they couldn't do before since it would break binary compatibility. One of the things that is different is that in the 32 bit runtime synthesized properties have to be backed by instance variables. On the 64-bit runtime synthesized properties sill needs that but they are created automatically for you. By default the name of the instance variable should be the same as the name of the property.
So in case you need to support 32 bit then make sure that you create instance variables for all your properties. If you only support 64 bit then you can still do that so that your code can be built for both 32 bit and 64 bit at the same time but you don't have to.
You can set the NS_BUILD_32_LIKE_64 preprocessor macro in Xcode for the the 32bit build target. This will save you the trouble of maintaining separate code for 32bit and 64bit versions.

compile lanshark on mac

I am trying to compile lanshark for mac, but do not know how to compile on mac. I am guessing that it is possible to compile linux source code on mac. if not how can i get this program to run?
A mac is, under the hood, a BSD 'darwin' box.
Go and take a look at the MacPorts webpage. You'll find lots of interesting information (like where to get a compiler etc ) there.
Another place to go for an apple development environment is apple (xcode) ...
It should be possible to get that to run, but it will be a bit of work. The source may need a small amount of modification, depending on exactly how the protocol works (if they're using raw ethernet, that is done quite differently). Also, the OS X linker (ld) works completely differently to the Linux linker, and so the build system will need a bit of tinkering.
However, the compilers and build utilities are in the XCode bundle on your install disk, or at the download link in the other answer, so install that and give it a go. If you're lucky, just following the Linux instructions will build it.

Resources