When trying to compile the most recent CUDA SDK from Nvidia (version 4.1.28) for linux, I get the following error:
error: identifier "CURAND_STATUS_DOUBLE_PRECISION_REQUIRED" is undefined
My google-fu yields only similar problems, and not solutions.
I have an older version of the SDK (version 4.0.17) which compiles fine. So this might be a bug in the SDK, or there is/are environment variable(s) I didn't set.
Not really an "answer", but an ugly quick fix is to comment out the line 328. It doesent impact my program, but there is no guarantee that it does not affect yours.
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 want to install intel opencl sdk. And surely I did everything written in intel opencl installation guide in intel's website.
http://software.intel.com/en-us/articles/intel-sdk-for-opencl-applications-xe-2013-release-notes#_Installation_Notes
I did everything written in there but it doesn't work.
Specifically, I can compile the source but it cannot find the platform at clGetPlatformIDs function. error code is -1001 and there's no -1001 error code at cl.h file. If I uninstall, then I cannot compile at all naturally. It means there's error message at compile time that it cannot find lots of functions and defined values. After I install the opencl sdk then there's no message and compile properly. I think it means that install is done properly. But at runtime, it cannot find platform. What's the problem? I've been struggling about one week. Please help me..
---add---
I forgot to let you know my OS.. and so on;;
My OS is Red Hat Enterprise 6.3 (Santiago).
My CPU is Intel Xeon CPU E5-2690.
The code I tried have no problem at other machines and platforms.
Thanks.
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.
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'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.