I am trying to run a LLVM pass and have the following version of gcc:
Configured with:
-- prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
I downloaded the LLVM 3.2 source from the official site and have that unzipped in my project folder.
From the project folder I am trying to run the following command:
opt -load /Users/jigs/Downloads/CS_298/llvm-3.1.src/lib/Transforms/LLVMHello.dylib -hello -S morph_1.s mul -o=morph_output.s
I get an error saying opt does not exist. I am pretty sure opt is a part of LLVM source but it does not work.
The opt tool should appear in the bin directory after building (yours will be version 3.x.x), so I believe you are looking in the wrong place altogether. The opt in tools is a directory, so that's certainly not going to do much for you.
/llvm-3.7.0.src/build/bin
$ ./opt -version
LLVM (http://llvm.org/):
LLVM version 3.7.0
DEBUG build with assertions.
Built Sep 8 2015 (17:54:06).
Default target: x86_64-apple-darwin14.5.0
Host CPU: ivybridge
If you don't have a bin directory present after compiling/building from source then something likely isn't correct within your makefile perhaps.
TIP: Often you can tell where the executables are that were built by looking at the most recently modified directory within the source tree. Also, I think the easiest and most hassle free way to build LLVM from source is to use CMake — it conveniently includes a CMakeLists.txt config.
Related
Mac 10.13.6 High Sierra here. New to C development and I'm trying to get myself setup with the latest stable/recommended GCC version, which I believe (keep me honest here) is 10.2.
When I go to the terminal to see what I have installed:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ gcc -dumpversion
4.2.1
OK...surprised to see LLVM/clang-related stuff in the output. So I try this:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
So its almost as if... I have both clang and gcc installed, but my clang installation has assimilated my GCC installation?! Why else would the gcc --version output reference clang?
Is this typical for Mac setups?
What do I need to do to get GCC 10.2 properly installed on my machine?
Here are some simple truths, statements and observations to try and explain what's going on:
Apple ships the clang/LLVM compiler with macOS. Clang is a "front-end" that can parse C, C++ and Objective-C down to something that LLVM (referred to as a "back-end") can compile
Clang/LLVM is located in /Applications/Xcode.app/somewhere
Apple also ships a /usr/bin/gcc which just runs clang. I have no idea why they do that - it doesn't seem very helpful to me - but they don't answer my questions
Apple puts its binaries (programs) in /usr/bin. That is an integral part of macOS and you should never touch or change anything in there - you are asking for problems if you do. This warning applies to Python too.
If you want the real, lovely GNU Compiler Collection (GCC) which includes the gcc, g++ and gfortran compilers, your best bet, IMHO, is to get them from homebrew. I will not put the installation instructions here because they could become outdated, so you should use the ones on the homebrew site.
Once you have homebrew installed, you can install the GNU Compiler Collection (GCC) with:
brew install gcc
After that, you will have all the lovely GNU Compiler Collection (GCC) of tools in /usr/local/bin, so you should put that in your PATH, near the beginning, and in any case before /usr/bin, using:
export PATH=/usr/local/bin:$PATH
In general, you should also add a similar line into your login profile, or into the system login profile, so it is set up every time you or any other user logs in.
Let's take a look:
ls /usr/local/bin/gcc* /usr/local/bin/g++*
/usr/local/bin/gcc-10
/usr/local/bin/g++-10
Depending on the versions and updates, you will then have these programs available:
gcc-10 # the real GNU C compiler
g++-10 # the real GNU C++compiler
gfortran # GNU fortran compiler
And you can check their versions with:
gcc-10 -v
g++-10 -v
gfortran -v
Now you know about homebrew, here are some more simple truths and observations:
folks (who are not the supplier of the operating system) who supply binaries (programs) for you should put their stuff in /usr/local to show that it is just a locally installed program rather than a part of the core macOS operating system
homebrew is well-behaved and installs its binaries (programs) in /usr/local/Cellar and then usually makes symbolic links from /usr/local/bin/PROGRAM to the Cellar. None of this interferes with Apple-supplied stuff.
if you want to run the homebrew version of a command, you should have /usr/local/bin first on your PATH
Let's have a look at those symbolic links:
ls -l /usr/local/bin/g*10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/g++-10 -> ../Cellar/gcc/10.2.0/bin/g++-10
lrwxr-xr-x 1 mark admin 31 21 Aug 16:41 /usr/local/bin/gcc-10 -> ../Cellar/gcc/10.2.0/bin/gcc-10
If you want to know what you are actually running when you enter a command, use the type command like this.
type gcc
gcc is hashed (/usr/bin/gcc)
That tells you that if you run gcc you will actually be running /usr/bin/gcc which we know is from Apple - because it is in /usr/bin
Now try this:
type gcc-10
gcc-10 is hashed (/usr/local/bin/gcc-10)
That tells you that if you run gcc-10 you will actually be running /usr/local/bin/gcc-10 which we know is from homebrew - because it is in /usr/local/bin
I'm starting to learn Haskell and I found out that ghc can compile using LLVM with the -fllvm flag. Whenever I use the flag, I get the error message:
<no location info>: error:
Warning: Couldn't figure out LLVM version!
Make sure you have installed LLVM 3.7
ghc: could not execute: opt
However, I have opt in my /usr/local/Cellar/llvm/3.9.0/ folder. I'm on a Mac OS X and I've installed the full LLVM with brew install llvm but error persists. Is this a genuine version problem where I have to unistall LLVM and reinstall its 3.7 version? Or is ghc having trouble finding opt and there is some kind of search path I can modify to fix the problem? Thanks for the help and have a great day.
The GHC documentation says that it's compatible with llvm-2.8+, but as you've discovered, it actually requires llvm-3.7.
The simplest way to get it is:
brew install llvm#3.7
This installs llvm binaries in your path with a -3.7 suffix, like clang-3.7. GHC will need the unadorned names, which are in a subdirectory:
export PATH=/usr/local/opt/llvm#3.7/lib/llvm-3.7/bin:$PATH
I'm developing some C/C++/Objective C static analysis utility which works with llvm bytecode files. Its basic idea is quite simple:
1. Utility executes clang/clang++ with arguments "-c -emit-llvm -femit-all-decls -g" to generate llvm bytecode file for tested source file.
2. If file was created it's being read by LLVM C bindings and checked. Problems related to some specific code points are reported with source references since there are debug metadata with source references.
I've had a prototype of my utility which worked fine, but recently I've updated Xcode to 6.1 and source references became missing.
To fix this I've tried to rebuild my tool and llvm static libraries with updated compiler, but it didn't solved my problem.
I've tried to receive any hints from llvm, and the only thing I finally got is:
➜ bin ./llvm-dis test.bc
warning: ignoring debug info with an invalid version (600054001) in test.bc
So llvm-dis has shown me above warning and produced test.ll file which was stripped of any debug metadata attributes.
This is my simple test source file which I'm playing with:
int returnFive() {
return 5;
}
and some info which may be helpful:
➜ bin clang --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
➜ bin ./llvm-config --version
3.5.0
➜ bin ./llvm-config --host-target
x86_64-apple-darwin14.0.0
For me this seems very compatible, but it isn't so maybe someone can give me any suggestions on how to resolve this?
While I'm still not comfortable with the solution, I've hacked LLVM code and removed the call to llvm::UpgradeDebugInfo method from BitcodeReader::MaterializeModule code. Of course I may be punished for this if some truly incompatible LLVM compiler is used, but for now it works, furthermore not only clang from XCode can be used, but as well I can use Clang from LLVM release page which also produces "debug info with invalid version (0)".
I'm trying to compile a project from the command line. The default compiler LLVM-clang and i need to compile with LLVM-gcc42. Switching a compiler in Xcode is really easy. However, on command line it seems to be more problematic. To my understanding "/usr/bin/cc" and "/use/bin/gcc" are used for pointing c/c++ compilers. I noticed that "cc" was linked to "clang" in same directory. So, i changed "cc" to point at "gcc". Did not helped. When i run
$ gcc -v
i get response
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
How do i change the clang to gcc?
My setup is:
MAC OS X 10.8.5
Xcode 4.6.2
Command line tools
EDIT 13.02.2014
The project is a QT project which uses mixture of third party c/c++ libraries. My task is to write a new objective C lib to it. The project is build with -spec macx-g++ parameter. The configuration scripts can be found /QTROOT/mkspecs/macx-g++ and /QTROOT/mkspecs/common. In g++-base.conf key variables are defined as:
QMAKE_CC = gcc
QMAKE_CXX = g++
Instead of changing links which can affect other programs use the full path to the llvm executables in your build script
e.g. if you have installed the command line tools
QMAKE_CC = /usr/bin/llvm-gcc-4.2
QMAKE_CXX = /usr/bin/llvm-g++-4.2
Okay, nailed the problem. Solution was simple. I deleted the old links from /usr/bin/gcc and /usr/bin/g++ and created new ones pointing to the proper compilers.
gcc -> /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
and
g++ -> /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-g++-4.2
I'm running Mac OS X 10.6 and want to install TextMate 2, which is for Mac OS X 10.7+.
But all what it needs is a newer version of clang (LLVM), which is included in Lion and Mountain Lion. I read before here I can do that with MacPorts. So I used port install clang and MacPorts updated to clang-2.9, then clang-3.2 and finally clang-3.3. I thought, its updated now and I checked the version: clang --version. And it's not updated:
Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix
So I copied the new clang file in this path (/opt/local/libexec/llvm-3.3/bin) to/usr/bin`. But now there's a fail :( :
dyld: Library not loaded: #executable_path/../lib/libLLVM-3.3svn.dylib
Referenced from: /usr/bin/clang
Reason: image not found Trace/BPT trap
The libLLVM-3.3svn.dylib is at /opt/local/libexec/llvm-3.3/lib. What can I do now, that
it runs clang-3.3? Sorry for my not perfect english ;) Thank you!
If you run clang from /usr/bin, it will be looking for the LLVM library in /usr/bin/../lib/libLLVM-3.3svn.dylib, i.e., /usr/lib/libLLVM-3.3svn.dylib (at least that's what the dynamic loader is telling you). You could try to copy the lib file into /usr/lib.
Alternatively, you can just download a more recent official build of Clang here:
http://llvm.org/releases/download.html
As far as I know, these builds are self-contained and do not need any dynamic libraries. However, it could be necessary to copy Apple's ARC libraries into a certain directory. If you run into trouble, please ask again.
Another approach is to build Clang and LLVM from source. You can find the repository URLs and instructions here:
http://clang.llvm.org/get_started.html
This should also build Clang with the LLVM libraries statically linked.
3.3, by the way, has not been officially released, so I would recommend using 3.2 unless you need any specific new features.