I'm trying to open one of my older projects, that was built using iOS 6.0. The project used to compile fine, but when opened under xCode 5, I get this cryptic error message.
Unsupported compiler 'com.apple.compilers.llvmgcc42' selected for architecture 'armv7'
Unable to determine concrete GCC compiler for file /Users/alexanderstone/Desktop/Development/RestKit/Vendor/NXJSON/NSError+Extensions.m of type sourcecode.c.objc.
Unable to determine concrete GCC compiler for file /Users/alexanderstone/Desktop/Development/RestKit/Vendor/NXJSON/NXDebug.m of type sourcecode.c.objc.
Unable to determine concrete GCC compiler for file /Users/alexanderstone/Desktop/Development/RestKit/Vendor/NXJSON/NXJsonParser.m of type sourcecode.c.objc.
Unable to determine concrete GCC compiler for file /Users/alexanderstone/Desktop/Development/RestKit/Vendor/NXJSON/NXJsonSerializer.m of type sourcecode.c.objc.
I've checked both project build settings, and they appear correct - LLVM 5.0 is selected as compiler for both.
Additionally, I checked the .m files that compiler complains about, and do not see any reference to GCC there. There are some ASSERT() and other macros, but I don't know if they are compiler-specific.
How can I resolve the llvmgcc4.2 compiler missing in xCode 5, when all subprojects appear to be set to llvm5.0?
Found this similar question. For me the solution was to go to Editor>Validate Project settings for both the child and the Restkit projects.
One solution of this problem is that i have resolved when i was facing this issue is just go to Build Settings-> Build Options-> Compiler for c++ set to Default and your problem wil be solved. see attached
Additionally, for opening in XCode 7 and for architecture 'i386', setting the compiler to 'Default compiler (Apple LLVM 7.1)' is one solution.
Related
I want to use some avx2 functions by including <immintrin.h> library in my project; however, Vscode does not seem to recognize these functions, as it is showing that my project contains various identifier "__m256i" is undefined errors as the attached pictures. I can compile and run smoothly, but the errors are really disturbing. I tried adding the declarations of these types into the Vscode path, but it does not help.
I am using the latest Vscode version in Centos 7.7.
Vscode show errors
Try added the include path, but does not help
__mm256i is a typo for __m256i.
The type names have 2 underscores and one m like __m128i
The intrinsic function names have one underscore and 2 ems like like _mm_add_epi32
I can compile and run smoothly, but the errors are really disturbing.
That's highly implausible, are you sure you're not running an old version of your executable from before you introduced this bug in your source? This is an error, not a warning; gcc won't produce a .o from a source file with this bug. Hard errors are the opposite of compiling "smoothly".
I solved the problem myself by restarting my computer. I think somehow at that time the computer did not recognize the definition of Intel AVX functions.
I am new to Xcode IDE, and I want to use omp library in my code. I am using an Apple M1 Macbook with MacOS 12.2.1, and Xcode 13.2.1.
In order to accomplish, I have read many references about this on the internet. But most of those posts I found were outdated. So I decided to ask again, although there may already have similar question asked by other. As I would also like to share the most updated way I found at the same time, of setting up clang in Xcode to others who also finding this.
I have referenced this website and try to setup Clang with omp in Xcode.
Since this website is not up to date, so I will briefly list what I have done until now below:
Install llvm with homebrew in the terminal:
brew install llvm
Specify a user-defined setting CC with the following value (brew installed clang is in /opt/homebrew for M1, referenced from http://antonmenshov.com/2017/09/09/clang-openmp-setup-in-xcode/):
/usr/local/opt/llvm/bin/clang
Search for the setting Enable Modules (C and Objective-C) and switch it from Yes to No
Add to the Library Search Paths the value:
/opt/homebrew/opt/llvm/lib
Add to the Header Search Paths the value:
/opt/homebrew/opt/llvm/include
Add the -fopenmp compilation flag to Other C Flags
Drag libomp.dylib file from /opt/homebrew/opt/llvm/lib to Build Phases->Link Binary With Libraries options in the main Xcode window
Set Enable Index-While-Building Functionality to No in Build Settings
After doing the above steps, I can now successfully build a C code with #include <omp.h>. But the problem now is that, Xcode always warning me 'omp.h' file not found in buildtime. An image showing the problem below:
May I ask how can I dismiss this error? Thanks.
I have been using gcc version 5.3.0. It says that it comes with openmp support. But every time when I compile a program using either gcc [by terminal] or via xCode 7, I get same error, "file omp.h not found". I have searched too much on this issue and tried almost everything I found.
First I tried to locate omp.h on my mac. I found some files; then in header file, I used that specific location of omp.h but no help [it gave me linker error].
I installed gcc version 6.0 (pre-release) but no help. I tried changing C_INCLUDE_PATH [which is now, and previously set to none] but that didn't helped me as well.
I reinstalled clang-omp but no help.
I am using llvm compiler version 7.0. Although i have installed clang-omp, there is no omp.h in my /usr/include/*
I changed the compiler and now I am able to run it. [It was issue of clang, which I couldn't solve].
I am a student and Intel is giving Intel Parallel Studio 1 year licence for free to students.
So I downloaded, and installed it.
In xCode, under build settings, I set my compiler to 'Intel C/C++ compiler' and in parallalization, I turned it to 'yes'. That was it. Then it compiled successfully. But, note that you won't be using header file 'omp.h' anymore.
By the way, I am still looking for answers, just to know what I was doing wrong.
You can install 'clang-omp' or 'gcc' (corresponds to GCC 5.3 right now) packages via Homebrew, both of which support OpenMP.
The built in GCC is based upon GCC 4.2.1 abs uses LLVM back end via Dragonegg, which is why it doesn't support OpenMP.
As noted already, Intel compilers support OpenMP on Mac.
I don't use Xcode editor so I don't know how to use any of these from there, but all will work from terminal just as they do on Linux.
the compiler on the mac is clang (based on llvm 3.5) which does not support openmp.
you can try install llvm/clang/openmp from source or using prebuild binaries, but I must admit it does not work as advertised for me…
edit unless you use the -fopenmp=libomp flag.
I'm trying to get started on using an ARM STM32F4 Discovery Board and I'm getting some weird compiling errors when using the "GNU Tools" on Windows 8
Currently my code is very simple:
#include "stm32f4xx_conf.h"
int main(void)
{}
This compiles using the "make" command perfectly find on Ubuntu 12 and windows 7, however I get the following error in Windows 8. I installed the same toolchain on all machines.
C:/Program Files (x86)/codesourcery/sourcery g++
lite/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:
error C:\Users\MyName\AppData\Local\Temp\cckUTM2f.o users VFP register
arguments, main.elf does not
I have narrowed down this error down to the flag "-mfloat-abi=hard", which when switched to "-mfloat-abi=soft", lets the code compile, however this conflicts other files that are previously compiled with "-mfloat-abi=hard".
Does anybody know why this would only occur on Windows 8 and how to fix it? If more information is needed, let me know. Sorry in advance if this is a nooby-question as I'm very new to this!
This answer may appear at the surface to be unrelated, but there is an indirect cause of this error message.
First, the "Uses VFP register..." error message is directly caused from mixing mfloat-abi=soft and mfloat-abi=hard options within your build. This setting must be consistent for all objects that are to be linked.
The indirect cause of this error may be due to the Eclipse editor getting confused by an error in the project's ".cproject" file. The Eclipse editor frequently reswizzles file links and sometimes it breaks itself when you make changes to your directory structures or file locations. This can also affect the path settings to your gcc compiler - for a subset of your project's files. While I'm not yet sure of exactly what causes this failure, replacing the .cproject file with a backup copy corrected this problem for me. In my case I noticed .java.null.pointer errors after adding an include directory path. I also found that a different path to the gcc compiler was being used for some of my sources that were local to the workspace, but not all of them. The two gcc compilers were using different float settings for unknown reasons - hence the VFP register error.
I compared the .cproject settings with a older copy and observed differences in entries for the sources causing the trouble - even though the overriding of project settings was disabled. By replacing the .cproject file with the old version the problem went away, and I'm leaving this as a reminder of what happened.
The solution was actually very simple, it was related to the PATH variable not being set correctly by the toolchain's installer. To solve it in windows 8, go to Environment Variables => System Variables and I added "C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\bin" to the path variable. The installer had put it under "User Variables for Name" and that, forever reason, didn't work.
We are in the process of moving our project from LLVM GCC to Apple LLVM. One of the libraries we have is built only for arm and not i386. This is causing issues where we get the warning on the simulator build after which we not end up linking anymore. This worked fine in GCC as I was able to compile the app just fine. This warning is harmless for us on the simulator. Is there any way to ignore the warning as it was on LLVM GCC.
I looked at the project build settings as well to figure out if there was a flag that I could use to switch off this warning.
I have looked enough stack overflow questions similar to this one. Most of them suggest to get both the flavors (arm and i386) of the binary and combine them. I still wonder how this worked in LLVM GCC and why there was no compilation error.
Any ideas ?
the warning that I get,
ld: warning: ignoring file library.a, file was built for archive which is not the architecture being linked (i386)
thanks