I was trying to use -dumpversion to determine if the compiler is usable.
My project compiles with clang and newer gccs, but not with the old gcc 4.2.1.
So why does clang pretend to be an old gcc?
Extra questions, is it possible to change this value at runtime?
Or does anyone have a nice autoconf macro to determine the compiler version with both clang and gcc?
Clang was originally written to be compatible with gcc 4.2.1. There has been some discussion about updating that number earlier this year, but there were issues.
For autoconf checking, clang suggests to use its __has_feature extension. Clang's document has a list of things you can check with __has_feature too.
Related
I've been trying to make the switch to LLVM, since I'd like to get more into the whole 'software-dev' scene, and it seems like right now, LLVM is the future. I built LLVM/Clang/LLD/compiler-rt/libcxx from source several times now, both with GNU/GCC and LLVM/Clang.
The problem appears when I try to use the newly compiled compilers. From what I can see, clang is using GNU ld rather than LLVM's lld. Is this true?
LLD seems to be a very limited program from the lld -help output, but from what I have read, it is as full featured as ld. I cannot find documentation on how to use it anywhere -- does anyone know where I can find some kind of comprehensive manual on it?
Thank you.
Pass -fuse-ld=lld to clang to make it use lld for linking. By now, it's in very good shape.
You can pass -v or -### to clang to make it print which linker command it runs or would run.
There's no manual for the moment and depending on platform may work well enough for you. That said, if lld were "production ready" we'd have switched clang to using it by default for the various platforms. It's not there yet so I wouldn't suggest you use it for your day to day development.
The LLVM team say that is production ready because FreeBSD can compile and link a lot of things with LLD.
The documentation on the LLD project can be found on http://lld.llvm.org/.
It's written :
LLD is a drop-in replacement for the GNU linkers.
That accepts the same command line arguments and linker scripts as GNU.
So you can use same arguments than GNU LD.
I know this question is old, but there is a newer solution to it:
To use the ld.lld linker when building any llvm target, just pass -DLLVM_ENABLE_LLD=ON in the commandline to cmake.
//Use lld as C and C++ linker.
LLVM_ENABLE_LLD:BOOL=TRUE
For other cmake projects, pass: -DCMAKE_LINKER=/etc/bin/ld.lld
I have a ModulePass that's working with the opt tool, but I'm having trouble figuring out how to make it available to clang at the command line. My current workflow for using my pass is:
clang -c -emit-llvm [c-source code files]
llvm-link [llvm bitcode files]
opt -load [PassName].so -[pass-name] [linked llvm file]
llc [resulting bitcode file]
gcc [resulting assembler file] -o [target]
I would like to get my pass integrated with the clang command line so that it could be invoked as part of the build of existing software (e.g. c++ standard library) without having to remake the whole build system for each thing I compile. I've seen hints about how to do this, but I haven't been able to put the pieces together into a working setup.
Run an LLVM Pass Automatically with Clang describes exactly what I want, but the method appears to be deprecated in LLVM 3.4 (PassManagerBuilder has been moved to the legacy namespace).
LLVM - Run Own Pass automatically with clang seems to address the basic issue, but I was hoping I could do this without having to modify clang (which seems to be what's suggested there).
What is the best way to make a new pass available from clang using LLVM 3.4?
Clang still uses PassManagerBuilder as of 3.5 (see the PassManagerBuilderWrapper class in BackendUtil.cpp). So I believe extending it with RegisterStandardPasses, as in my blog post, is still the only way to add a pass to Clang's pass manager.
It's frustratingly difficult to find any information about how deprecated the "old" pass manager infrastructure is. But since Clang is still using it, it can't be that deprecated. :)
I've installed xcode 5 and noticed that gcc compiler is deprecated. Assuming that I don't want to switch to Apple LLVM 5.0, here come my questions:
Is it possible to use iOS7 SDK and still compile in llvm-gcc-4.2?
If yes, how to do this?
If you don't know if that's possible, please don't post answers like "use clang, man", because they are not actually answering the questions I've posted.
Apple has removed the support for llvm-gcc-4.2 in XCode 5. Even if you install and change your base sdk to 6.1 sdk, you won't be able to build using llvm-gcc-4.2. So your only option is to continue using XCode 4.x if you want to use llvm-gcc-4.2.
LLVM-GCC is not included in Xcode 5.
I got above line from
https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_5_0.html
So the question is what to use instead of llvm-gcc ?
Is it possible to use iOS7 SDK and still compile in llvm-gcc-4.2?
If you want to compile your whole app using llvm-gcc-4.2: Probably not. I haven't checked this myself, but the iOS 7 headers would only need to add a single dependency on a clang feature missing in llvm-gcc-4.2 and you're swimming in compile errors. You may be able to hack your way through them, but it would likely be easier (not to mention more future-proof) to suck it up and upgrade to clang.
If you only need to compile some of your app using llvm-gcc-4.2: Sure, as long as you don't need to import any iOS 7 headers in the parts that you build with llvm-gcc-4.2.
You could try moving the problematic bits off to a static library, compiling that with gcc, then linking in to the final app, built with clang. You won't be able to target 64-bit, as llvm-gcc-4.2 doesn't can't generate armv8 code, but it should work otherwise.
One caveat: If your static lib uses C++, there may be some problems due to ABI and std library differences. But those are solvable problems, at least.
You could use homebrew to install the gcc version you need. Most probably all your Makefiles will need to be corrected (sigh)
I did:
brew search gcc
And the results:
homebrew/versions/gcc43
homebrew/versions/gcc45
homebrew/versions/gcc47
homebrew/versions/gcc49
homebrew/versions/gcc44
homebrew/versions/gcc45
homebrew/versions/gcc48
homebrew/versions/llvm-gcc28
homebrew/dupes/apple-gcc42
Does latest XCode's Apple LLVM compiler 3.0 support collecting code coverage data from physical iPhone machine? If yes, how to set it up?
Below gives a solution for gcc compiler. But I want to know whether this is a workable way for LLVM compiler 3.0. Because for our project, when switching from llvm compiler to LLVM gcc, we got some compiling errors, so we'd like to stick to apple's llvm compiler.
https://stackoverflow.com/questions/5101014/code-coverage-not-showing-results-using-xcode-
gcov/5140459#5140459
I found a solution for this.
http://www.gerardcondon.com/blog/2012/02/21/code-coverage-updates-for-xcode-4-dot-3/
And I can get the coverage data from device now. But met another issue when parsing the gcdata. The gcdata collected is marked as 4.2 version, while the gcno files generated by Apple Compiler 3.0 is 4.4. When using lcov which calls gcov(by default 4.2.1) to generate cov info file, it failed to parse the gcdata. I have tried to install a new version of gcov(gcc4.4.7), but still failed. I am still doing some investigation on this. Hope I don't need to write my own lcov. :-)
Thanks.
I'm developing iOS apps and I've just upgraded my Xcode to 4.2.
I see that the GCC 4.2 compiler is no longer available.
Can I still link my static library, which was previously compiled with GCC 4.2? Would it cause any problems?
Very probably yes. ABI conventions don't change much. However, since it is your static library, I assume you still have its source code. Then it is better to recompile in with a recent compiler (like GCC 4.6) and with -Wall flag. GCC compiler is improving from version to version (particularily since 4.2 which is several years old), in compliance to language standards, in diagnostic abilities (better warnings), and in optimization.