On OSX Mountain Lion I'm able to compile mach_inject and the included test project. That works as expected with injection functioning perfectly.
I'm now trying to use the same mach_inject framework from a Qt project, compiled from QtCreator. I've tried both clang and gcc compilers.
Everything compiles and the application runs, but when calling mach_inject, I get the error:
mach_inject failing.. (os/kern) invalid address
Tracing mach_inject, the failure occurs at the last step, when it calls thread_create_running.
Does anyone know what the problem is here? I'm assuming it's something to do with the compiler options provided by Qt against those used by XCode, but could be totally wrong!
Thanks.
The problem turned out to be a 32 / 64 bit incompatibility - as (naturally) you can't inject a 64bit bundle into a 32 bit app!
If anyone else has similar problems, debugging into the mach_inject_bundle_stub can be of use, as the same error from the kernel can be presented due to other issues.
Related
I am new to gem5 and I am trying to install the simulator on my iMac pc (OSversion: High Sierra 10.13.6).
All the dependencies specified on the site have been installed to the correct version. The problem i am currently stuck with is that when i try to first compile M5 in the gem5 directory with 'scons build/ARM/gem5.opt', it stopped with errors mostly being:
**/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3656:5: error: destructor called on non-final
'Stats::BinaryNode<std::__1::multiplies<double> >' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]**
__data_.second().~_Tp();
^
I couldn't find any relevent answers regarding this. I hope if there are any amazing MAC gem5 developers out there can help me with this.
cheers!
I mailed to Mr Andreas Sandberg. The answer worked for me:
"I think the compiler version you are using uses more aggressive warnings than default (and possibly a newer C++ standard than we normally use). I would suggest disabling -Werror and see if that makes a difference."
Try disabling -Werror with the next command line :
export CFLAGS="-Wno-error"
Hope work for you.
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.
OCaml programs which worked perfectly on Lion fail on Mountain Lion, segfaulting on startup in OCaml runtime code:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff908e1f88 in large_malloc ()
There appears to be a widespread problem with the native-compiled (ocamlopt) OCaml runtime when backtraces are enabled which is new to Mountain Lion. This same crash affects the startup of any OCaml binaries which are:
Native compiled (as opposed to bytecode)
Run with backtraces enabled (e.g. via OCAMLRUNPARAM=b)
This even includes parts of the OCaml compiler toolchain, itself, which will suddenly stop working after an upgrade to 10.8.
This still affects the OCaml SVN trunk (4.01.dev) as of 2012-07-19.
The workaround is to disabled backtraces when working with native compiled binaries (unset OCAMLRUNPARAM, or remove b from your parameter string).
update:
The underlying bug appears to be due to insufficient stack alignment in the OCaml runtime implementation. Since the originally post, this is now being tracked and fixed on the OCaml bug tracker. For now, however, the workaround remains the only simple choice.
The problem may be solved, there's an explanation and a patch here in OCaml's bugtracker.
I've spent some time today playing with getting the source for python 3.1.1 to build on my MacBook Pro using the --enable-framework and --enable-universalsdk options with no success. I will humbly admit that I have no real clue why I can't compile 3.1.1 on Snow Leopard, I did make sure to get the new Xcode version for Snow Leopard, and made sure I also installed the 10.4u SDK. It seems to be choking on the 10.4 SDK during the make stage, and has several error regarding headers for wchar, cursor, and ncursor during the configure stage. I have been able to get a make from a plain configure, and most the test pass, but that just isn't challenging enough. Has anyone else attempted to build python 3.1.1 on a Mac running Snow Leopard
There is an automated installer here: http://python.org/ftp/python/3.1.1/python-3.1.1.dmg
You need to set MACOSX_DEPLOYMENT_TARGET if you actually want to use an older SDK.
If you target 10.6, it may be that PPC building is not supported anymore, according to this bug report. In fact, that may be the case even if you target 10.4, using XCode 3.2 (haven't tried myself).
I don't have 10.6 installed yet so I can't say for sure it will work without issue but, in general, if you want to build a batteries-included framework build optimized for 10.6 of Python on OS X, you're best off using the installer build script in the source tree at Mac/BuildScript/build-installer.py after applying the patch in the bug report Martin referred to. Something like this should work [untested]:
./build-installer.py --sdk-path=/Developer/SDKs/MacOSX10.6.sdk --universal-archs=intel --dep-target=10.6 --src-dir=... --build-dir=...
That will build everything including dependent third-party libraries and the documentation but, be forewarned, you'll probably have to tweak things until you get it right and a few things aren't supported yet in 64-bit, most notably, tkinter. As mentioned above, the standard python.org 3.1.1 installer should likely work OK as long as you don't need 64-bit support.
[EDIT: I should clarify that, WRT 64-bit support, the problem isn't in tkinter, rather that the Apple-supplied versions of Tk in 10.5 and earlier were 32-bit only and so there was code in setup.py to prevent attempting to build a 64-bit version of tkinter on OSX. Perhaps that check can be removed now if the 10.6 Tk is 64-bit.]
Kenneth Reitz's soluton doesn't work for me. In fact, the install works fine but my default PATH still points to /usr/bin/python (v2.6.1.). I vaguely recall that we should be modifying our ~/.profile to point to /.../Frameworks and I expected the installer to do this for me (nope).
Anyway, /Library/Frameworks/Python.framework/Versions/3.1/bin exists so we could add it.
But I'm curious why the python bin in there does a crash and burn on me.
No time to resolve this now. Bye.
I'm trying to compile a Mac version of our lib for a customer that wants to include it in a Photoshop plugin, and he is having trouble linking our lib into his app. More detailed info: His plugin is built against the CS4 Photoshop SDK, which means the Mac OS base SDK should be 10.4. My lib is a static one, compiled with the Intel compiler 11.1 and the base SDK is also set as 10.4.
I tested my lib against a small test app I wrote, and it compiles and works fine (on 10.5). To replicate my customer's environment, the app is compiled with gcc, and uses the 10.4 base SDK. While its fine for me, my customer cannot manage to link with my lib. The problem is the following: Undefined symbols:
"_fputs$UNIX2003", referenced from:
_write_message in libMyLib.a(libm_error.o)
When I compile my lib with gcc,and all other project settings the same, its fine, he can generate an executable. As soon as I compile with ICL, it breaks down. Could it be that ICL 11.1 is not compatible with 10.4? On the Fortran compiler forum, I found the following answer:"From the output provided it appears Xcode defaulted to Mac OS X 10.4, which the 11.1 compilers do not support." (http://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/68647/)
Does that mean ICL 11.1 does not run on 10.4, or that the code it generates doesn't work on 10.4??
On the following page (http://software.intel.com/en-us/articles/performance-tools-for-software-developers-compatibility-of-intel-compiler-for-mac-os-x-and-xcode/), it also says that ICL 11.1 is not compatible with 10.4 (again same question: what does compatibility mean?). However, it says that ICL 10.1 is, so I tried. But now, even my own test app does not link, for the same reason (undefined function$UNIX2003).
Does anybody know what is the problem, and how to fix it? Or a way to work around it?
Thanks in advance,
A
PS: bonus point if somebody knows what this one means:
ld: absolute addressing (perhaps -mdynamic-no-pic) used in _Cholesky from libMyLib.a(Cholesky.o) not allowed in slidable image. Use '-read_only_relocs suppress' to enable text relocs
So the answer is: compile with ICL 10.1, not 11.1. None of the Intel libs used by 10.1 contain references to $UNIX2003 routines.
Hope it helps somebody.
A
Ultimately, you're going to need to get Intel product support from Intel, but if you want to sell Mac software that actually works then you should probably just use the same toolchain as everyone else and forget about it.