Does anyone know if precompiled headers are supported when using Clang++ 2.0? I've installed Xcode 4 Developer Preview 2 which includes a Clang++ build that reports its version as "Apple clang version 2.0 (tags/Apple/clang-108.3))", but trying to replicate the basic PCH usage example at http://clang.llvm.org/docs/UsersManual.html#precompiledheaders for a C++ program with some STL headers in the PCH doesn't seem to work, i.e. build times are the same either way (~350ms in my case).
My guess is that PCHs for Clang++ just aren't supported fully at this stage, or for some reason you don't get much benefit from them, but maybe someone else knows more details?
The PCH created by Clang++ is ~2.5MB.
Thanks.
Looking at recent Clang commits reveals that C++ precompiled header support is present as of r110879, committed on 12 August 2010.
I checked out the LLVM and Clang sources and tested it - compile time went down by ~2.5x - nice!
This feature will no doubt make it into the next Xcode 4 prerelease/beta from Apple.
Related
I have a peculiar setup, but necessary out of business decisions outside of my control.
I am running macOS 12 on Apple Silicon, have Xcode 9.2, am able to compile and link, by specifying the actual compilers inside the Xcode package, and specifying a more up to date version of ar and ranlib to CMake (the Xcode 9.2 versions give runtime errors on newer systems), basically like this:
-DCMAKE_C_COMPILER=/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-DCMAKE_CXX_COMPILER=/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-DCMAKE_OSX_SYSROOT=/Applications/Xcode_10.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
-DCMAKE_OSX_ARCHITECTURES=x86_64
-DCMAKE_AR=/usr/bin/ar
-DCMAKE_RANLIB=/usr/bin/ranlib
These options work and let e.g. Xcode 10.1 tools be usable and we can build our software on newer OS versions, but in the XCode 9.2 case, we fail in linking OpenGL:
ld: can't map file, errno=22 file '/Applications/Xcode_9.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework' for architecture x86_64
Due to the commandline option passed to Clang:
/Applications/Xcode_9.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework
Which seems to think that it is a file, while it's a framework (directory). Changing this manually to
-framework OpenGL
makes everything work as expected. But that's not what CMake provides.
The question now is: how do I make CMake use this option instead of just passing the OpenGL framework directory path to Clang (with as little change to our CMake files as possible). We currently link any targets using OpenGL using the imported targets provided by find_package(OpenGL REQUIRED):
target_link_libraries(... PRIVATE OpenGL::GL)
And ideally I'd like to keep this the same as there's many of these in our solution.
UPDATE: I hit an additional snag, which seems to be that things like Qt5's cmake scripts are also adding the OpenGL framework directories outside of my OpenGL::GL usage. So perhaps a better approach would be to find a functional ar/ranlib on M1 that can handle what Xcode 9.2's ar/ranlib can handle.
If you want to link specifically with -framework OpenGL, you should change your target_link_libraries line to look like this instead:
target_link_libraries(${PROJECT_NAME} LINK_PUBLIC "-framework OpenGL")
I believe this removes the need for find_package(OpenGL) as well.
The issue is about linking x86_64 macOS executables statically against libavcodec, libavdevice, etc, which have some object files built against freestanding as they use YASM which isn't able to embed the macOS "tag" in the binary (see Building for macOS, but linking in object file built for free standing for detailed information on that issue).
Everything works fine under Xcode 11.6 - the following messages are here, but they are warnings.
With the Xcode 12 update they become an error.
How to make them warnings again ? I could not find anything relevant in the ld man page.
ld: in ffmpeg/lib/libavcodec.a(aacencdsp.o), building for macOS, but linking in object file built for free standing, for architecture x86_64
There is no option I have found to revert the error to a warning. Apple has been warning us about this issue for a few releases of XCode now and the warning has become an error.
Until NASM is modified, or we can use some other assembler, the only option that allows me to build and link against the libav libraries in my application is to disable assembly when compiling ffmpeg.
./configure --disable-asm
This works my my case, as the performance of the non-assembly code path is acceptable in my desktop authoring tool. The server-based renderer still uses the assembly code path as it is linux based.
You may have to configure any libaries that you are including in your ffmpeg build to also disable assembly.
Once again, this is an acceptable solution for my case, as the non-assembly code paths are fast enough for my use case.
I have a serious issue getting Xcode 7.3 to compile a Project against Mac SDK 10.7 with LLVM (7+) and C++11. The source of the issue seems to be Xcode or the fact that I'm running OS X 10.11. Some colleagues of mine don't have the same issue compiling the same issue with older Xcode Versions (6). Here is the general setup:
The needed Libraries and Headers are linked with CMake. The Include paths of everything got checked multiple times. The created Xcode Project also seems to be ok, we've compared all important settings (C++ dialect, std library , target, defines etc) against systems where the project does compile.
The actual error comes when compiling vecLib source.It seems to be a set of random error messages I would trace back to the lack of c++ std headers.. Here are a few examples:
Explicite specialization of non-template class 'complex'
Redifinition of complex as different kind of symbol
Did anybody run into similar problems when working with newer Xcodes against older SDKs?
EDIT
Here is some more informations. After checking what was behind the redifinition, I found that for some odd reason, the complex definition that was interfering with the forward declaration in the file comes from /usr/include/c++/4.2.1. I think that the header is outdated or at least not compatible with c++11. I checked again what the compiler used and the lib / language (std=c++11 and stdlib=libc++) where correctly set. I have the strange feeling that the source in user/include isn't supposed to be included but I don't know how to fix it.
EDIT 2
I've checked the standard include paths with cpp -v and got the following list:
/usr/local/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/bin/../lib/clang/7.3.0/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
The definition of complex in the Xcode toolchain (3rd entry) is the correct one, the definition in /usr/include is the one that seems to be used while compiling, leading to the error messages. The definition of complex uses structs.
What is the issue here? Is the issue that Xcode / Clang or what ever decides to go with usr/include instead of the toolchain include? I've checked the project settings and the compiler output and there was no explicit include of this path.
It seems like AppleClang 7+ and libc++ just doesn't support vecLib from OS X SDK 10.7. I had to go back to Xcode 6 to get it to build.
I am currently writing c++ code and compiling using Xcode. I was wondering: How can I find out which c++ compiler is Xcode 5 using?
I would like to know that to make sure that the program I am writing is compilable on other computers that don't necessarily use the same compiler.
Thanks in advance!
You can also check your target's build settings to see what the current setting is. However, Xcode 5 only uses the LLVM 5.0 compiler. GCC is no longer used.
https://developer.apple.com/technologies/tools/features.html
On most projects, If I change the compiler I'm using from "apple llvm compiler 4.1" to "llvm gcc 4.2", the compiler options available later on in Build settings will change accordingly.
Right now, I'm doing a project using objective-c++ , but I'm noticing the compiler options don't update (see screenshot below). Anyone ever experienced this? Is there a way to fix this without creating a brand new project?
I was trying to switch to the apple llvm compiler to try using ARC (and yes, I've read http://philjordan.eu/article/mixing-objective-c-c++-and-objective-c++ and it's recommendation to not use ARC in this scenario).
NOTE: I'm using Xcode Version 4.5 (4G182)
I had the same problem and solved it by editing my project.pbxproj file using a text editor. I had inconsistent settings of "GCC_VERSION" in the file. I quit Xcode and then simply deleted all the lines with GCC_VERSION in them. Restarted Xcode and suddenly I got the default compiler (apple llvm) and all the appropriate compiler options.
Click the "All" label on the top gray bar, and all the options will show up: