I often need to target Mac OS X versions that are older than the one I'm currently running. As I prefer to work with a bash shell and Makefiles, I do not use Xcode. Apple explicitly supports targeting older OS X versions, but I've always been confused by the redundancy of the two configuration steps that are usually taken to target older platforms:
gcc is started using --macosx-version-min:
gcc --mmacosx-version-min=10.6 ....
The MACOSX_DEPLOYMENT_TARGET environment variable is set to the desired platform, e.g.
export MACOSX_DEPLOYMENT_TARGET=10.6
When trying to figure out the actual difference between the two by searching, you'll come up with different answers. Some people say that they do exactly the same, so it's only necessary to use one of the two. However, there are also voices which say that it's necessary to do both: start gcc with --macosx-version-min and set the environment variable.
Are these two things exactly the same? Is it only necessary to use one of the two but not both? Is there some official documentation available somewhere? Apple mentions MACOSX_DEPLOYMENT_TARGET but doesn't mention --macosx-version-min at all, even though it seems to be much more common.
The man pages of gcc on Mac OS X say that they're synonymous:
-mmacosx-version-min=version
The earliest version of MacOS X that this executable will run on is
version. Typical values of version include 10.1, 10.2, and 10.3.9.
This value can also be set with the MACOSX_DEPLOYMENT_TARGET environment
variable. If both the command-line option is specified and the
environment variable is set, the command-line option will take precedence.
Keep in mind, that apple changed default compiler to clang. Currently clang tries to translate gcc flags to his own. But it doesn't cover 100%. So it might happen that -mmacosx-version-min will stop working one day.
Related
The Perl community has relied on MACOSX_DEPLOYMENT_TARGET=10.3 for all builds of Perl for, well, a long time. But now, with the El Capitan beta, it no longer works. It seems as though they should bump it up, but to what? Is there a way to programmatically set it to whatever is the earliest version supported by the release of OS X on which Perl is currently being built? Or is there some other way to set it dynamically? Or must it be static and updated periodically? If the latter, how does it affect builds on older versions of OS X?
This should be a fairly simple change in hints/darwin.sh, that checks what OSX version is running and sets MACOSX_DEPLOYMENT_TARGET accordingly.
Perl is an Open Source project, and as such always short on developer time. If you were to make a patch for this and submit it to p5p, I'm sure it would be greatly appreciated.
Accepted #Calle-Dybedahl's answer, as it's technically correct. Perl 5 Core Hacker Jarkko Hietaniemi pushed this solution, which proved to be a bit more complicated than you might expect at a glance. The basic recipe he came down on was:
For OS X 10.6 or above, do not any more use the MACOSX_DEPLOYMENT_TARGET,
the toolchains should work fine without. Until now the deployment target
was hardwired to 10.3. This logic comes from
RT#117433.
For OS X releases from 10.3 until 10.5, no change, still using
the MACOSX_DEPLOYMENT_TARGET=10.3 for linking.
For OS X releases before 10.3, no change, still not using
the MACOSX_DEPLOYMENT_TARGET=10.3.
New: always add -mmacosx-version-min to ccflags and ldflags from
the env var $MACOSX_DEPLOYMENT_TARGET, if set. If the var is not set,
set the min from the OS X version, from sw_vers(1). Setting the var
should become handy for people building and packaging Perl for earlier
OS X versions.
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.
I am sort of switching to a Mac based development environment as the Mac line of laptops and workstations contains some very nice systems, albeit pricey. As an occasional Emacs developer, I want to build Emacs from the git/bazaar sources. Much to my surprise, the first time I attempted to do this using Xcode4, I discovered that the version of autoconf supplied with Xcode is less than that required by Emacs. So this raises the question: what approaches do those who develop Emacs daily using Mac hardware take in order to have the required libraries and headers available to build and run the Emacs development code on OS X? Left to my own devices, I will fetch and build the versions of components required by Emacs that are not satisfied by Xcode and put those into /usr/local/... but it does occur to me that other approaches, using fink for one example, might be less work and/or more satisfying, hence the question. This also applies to the add-on packages for graphics support (pdf, dvi, png, etc.) that are not supplied by Xcode.
The directions in the file nextstep/INSTALL is to issue the following commands:
./configure --with-ns
make install
The resulting "app" can be found in nextstep/Emacs.app.
However, there is an XCode project provided with Emacs, but I haven't got it to work.
I use the macports package 'emacs-app', which is just emacs configured --with-ns. They're currently at version 23.2.1
Even if you want to build emacs direct from GNU repos, using macports to get autotools should save you some time and energy. The autoconf package is at 2.68, and emacs configure.ac requires 2.65
I'm building an application that takes advantage of Mac OS X 10.6-only technologies, but without giving up backwards compatibility to 10.5 Leopard.
The way I do this is by setting the 10.6 SDK as the base SDK, weak-linking all frameworks and setting the deployment target to 10.5 as described in:
http://developer.apple.com/mac/library/DOCUMENTATION/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
This works fine; before making a call that is Snow Leopard-only I need to check that the selector or indeed the class actually exist. Or I can just check the OS version before making the call.
The problem is that this is incredibly fragile. If I make a single call that is 10.6 only I blow Leopard-compatibility. So using even the normal code code completion feature can be dangerous.
My question: is there any way of checking which calls are not defined on 10.5 before doing a release build? Some kind of static analysis, or even just a trick (a target set the other SDK?) would do.
I obviously should test on a Leopard machine before releasing anything, but even so I can't possibly go through all paths of the program before every release.
Any advice would be appreciated.
Best regards,
Frank
You could change the target SDK to 10.5. The compiler will then output warning: definition for '-snowLeopardOnlyMethod:' not found messages.
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.