I am using Haskell's GHC to create LLVM code but it cannot find opt from LLVM. I googled the problem and it was recommended to install LLVM from homebrew, which I did, but there's no opt binary on my path. I am wondering where I can get it from so I compile LLVM code from GHC?
The only solution I found was to download the prebuilt binaries from the LLVM web site: http://llvm.org/releases/download.html
Homebrew is quite explicit about how it installs LLVM:
~$ brew install llvm
==> Downloading https://homebrew.bintray.com/bottles/llvm-3.6.2.mavericks.bottle.tar.gz
Already downloaded: /Library/Caches/Homebrew/llvm-3.6.2.mavericks.bottle.tar.gz
==> Pouring llvm-3.6.2.mavericks.bottle.tar.gz
==> Caveats
LLVM executables are installed in /usr/local/opt/llvm/bin.
Extra tools are installed in /usr/local/opt/llvm/share/llvm.
This formula is keg-only, which means it was not symlinked into /usr/local.
OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.
Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:
LDFLAGS: -L/usr/local/opt/llvm/lib
CPPFLAGS: -I/usr/local/opt/llvm/include
==> Summary
🍺 /usr/local/Cellar/llvm/3.6.2: 811 files, 291M
so what I did was simply export PATH=/usr/local/opt/llvm:$PATH prior to executing any GHC commands that required LLVM.
Related
I am installing a package (called CLASS, widely used in cosmology) which cannot be compiled with Apple's gcc.
I tried installing gcc by homebrew (gcc-9) and anaconda separately. But both of them could not find the standard C-library files such as stdio.h, math.h etc. I saw this problem very common in mac. I found the standard C-library files at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/. Focusing on anaconda gcc (version 4.8.5), I then copied the files to /Users/satadru/anaconda2/include/. Now simple C-codes, such as a 'hello world' code runs fine. But when I tried to install the CLASS package, I get error arising from the problematic library files: stdio.h, math.h!! I get same error when I try to install the package using homebrew gcc-9 (after copying the library files to its concerned directory). I know that many people could run the package on catalina without any issue.
Now I have the following questions:
Are all standard C-library header files same? In other words, be it anaconda gcc 4.8.5, or gcc-9, the header files are same? Do the header files vary on different os, say linux or mac os?
Does anaconda gcc look for the header files at /Users/satadru/anaconda2/include/?
Before copying all the header files to /Users/satadru/anaconda2/include/, the directory had a few present there.
Why does not anaconda gcc installation place all of its own header files in this directory at the time of installation? Is it same when we do it on linux os?
How to solve my problem? I contacted the owner of the package and he says he himself runs the code on mac os catalina, but never faced this issue.
More information:
xcode-select --install
gives
xcode-select: error: command line tools are already installed, use "Software Update" to install updates
which gcc gives /Users/satadru/anaconda2/bin/gcc
gcc -v gives
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/satadru/anaconda2/bin/../libexec/gcc/x86_64-apple-darwin11.4.2/4.8.5/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure --prefix=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-gxx-include-dir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/gcc/include/c++ --bindir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/bin --datarootdir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/share --libdir=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib --with-gmp=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-mpfr=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-mpc=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-isl=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-cloog=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac --with-boot-ldflags='-Wl,-headerpad_max_install_names -Wl,-L/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib -Wl,-L/usr/lib' --with-stage1-ldflags='-Wl,-headerpad_max_install_names -Wl,-L/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib -Wl,-L/usr/lib' --enable-checking=release --with-tune=generic --disable-multilib
Thread model: posix
gcc version 4.8.5 (GCC)
My ultimate goal is to get python package graph_tool working on my system and also on ipynb if possible. I have already brew install graph-tool, as indicated here, but that's still insufficient.
So I follow conda instructions here, and I make decent progress, until I encounter a compiler issue with the configuration.
$ conda create -n py36env python=3.6.3 anaconda
(py36env) $ conda install -c conda-forge cgal
... and so forth with the other required libraries
(py36env) Tams-MacBook-Pro:graph-tool-2.25 tamtam$ ./configure --prefix=/Users/tamtam/anaconda3/envs/py36env/ --with-python-module-path=/Users/tamtam/anaconda3/envs/py36env/lib/python3.6/site-packages
.
.
.
checking whether g++ supports C++14 features by default... no
checking whether g++ supports C++14 features with -std=gnu++14... no
checking whether g++ supports C++14 features with -std=gnu++1y... no
configure: error: *** A compiler with support for C++14 language features is required.
I'm not very familiar with compiler things, but I check my system as follows:
(py36env) Tams-MacBook-Pro:graph-tool-2.25 tamtam$ conda list | grep gcc
gcc 4.8.5 8
And outside of the conda env:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/tamtam/anaconda3/envs/py36env/bin/../libexec/gcc/x86_64-apple-darwin11.4.2/4.8.5/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure --prefix=/Users/ray/mc-x64-3.5/conda-bld/gcc-4.8_1477649012852/
Thread model: posix
gcc version 4.8.5 (GCC)
And with Homebrew
$ brew list --versions | grep gcc
gcc 7.1.0 7.2.0
$ /usr/local/bin/gcc-7 --version
gcc-7 (Homebrew GCC 7.2.0) 7.2.0
$ echo $PATH
/Users/tamtam/anaconda3/bin:/Users/tamtam/anaconda/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin
So my questions are: EDITS INCLUDED
1) What's the difference between the conda gcc 4.8.5 and Homebrew gcc 7.2 on my system? I'm confused because they're each up-to-date packages.
EDIT: Nowhere online that I perused explicitly states this, but I am understanding (aka educated guess bc it's 3am and I need sleep) conda gcc 4.8.5 to just be equivalent to brew gcc 4.8.5, and that Anaconda is just way behind on developing an 'official' gcc supporting C++14. In the meantime I conda install -c salford_systems gcc-5 and ./configure seems to find itself a C++14 compiler. YAY (but this also led me to a new problem T.B.A.)
NOTE: I had also tried running the ./configure file with both conda gcc 4.8.5 and brew gcc 7.2.0 (switching of default gcc compiler guided here), but still same error of ./configure not finding C++14 compile (so ignore this)
2) I also have Xcode 8.3.3 that also comes with clang, which is what gcc is symlinked to... ?? No idea about the setup/relation
3) How can I adjust my system (for example, paths) so that the configuration process will detect a C++14 compiler? EDIT: resolved per 1)
(This solution is also included within the edits at the bottom of my question.)
Nowhere online that I perused explicitly states this, but I am understanding (aka educated guess bc it's 3am and I need sleep) conda gcc 4.8.5 to just be equivalent to brew gcc 4.8.5, and that Anaconda is just way behind on developing an 'official' gcc supporting C++14. In the meantime I conda install -c salford_systems gcc-5 and ./configure seems to find itself a C++14 compiler. YAY (but this also led me to a new problem)
NOTE: I had also tried running the ./configure file with both conda gcc 4.8.5 and brew gcc 7.2.0 (switching of default gcc compiler guided here), but still same error of ./configure not finding C++14 compile arises (so ignore this)
As a rule of thumb, if a product provides its own build tools (compiler, C headers, static libraries, include/library paths etc) instead of using the system's ones, you should use those when building things to use within its environment.
That's because, depending on include files, compiler, compiler version, compiler flags, predefined macros etc the same sources and libraries built with different toolchains can be binary incompatible. This goes double for C++ where there are no ABI standards at all. (In C, there are de facto ones for most platforms where there are competing compilers due to the need to do system calls.)
Now, what you have on your system:
The system's stock gcc (if any) is at /usr/bin (so includes are at /usr/include, static libraries at /usr/lib etc)
Homebrew's gcc 7.2 at /usr/local/bin (includes are probably at /usr/local/include)
Anaconda also has a gcc package that, if installed, would reside somewhere like /Users/<login>/anaconda3/envs/<env name>/bin
If an environment provides an own toolchain, it provides some way to make build scripts select that toolchain when building things. A common way is to set relevant environment variables (PATH, INCLUDE, LIB) - either directly or through some tool that the environment provides. Homebrew executables reside in /usr/local/bin which is always present in UNIX PATH as per the FHS; Anaconda adds itself to PATH whenever its environment is activated.
So, as you yourself guessed, since Anaconda provides its own gcc packages (thus enforces the compatibility of their output with its binary packages via package metadata - if there are known incompatibilities, the installation will fail due to requirement conflicts), you need to install one that meets graph-tool requirements -- which is gcc 5, available via gcc-5 package from salford_systems channel. Then specify --prefix as you already have.
You may need to install other dependencies, too, if you didn't already or you need optional features that they're required for.
I eventually want to use valgrind to find what is causing the occasional bizarre output in a C program which refines a model against experimental data using OpenMP parallel programming.
To avoid the use of the nominal gcc (ie clang) compiler, I used brew to install gcc-4.9 on my MacPro running Yosemite (OS x 10.10.5). However, when trying to compile my program with gcc-4.9, with or without -fopenmp, I get numerous error messages of the type:
/var/folders/qc/1j0gr_l48xnfd9001s6tt6f80000gn/T//ccRxnrnU.s:30597:suffix
or operands invalid for `movq'
I have no idea what the problem triggering these error messages is. Can anyone help?
The following summarises what was worked out in the comments section and did lead to the issue being resolved. Not all steps may be necessary, but most are probably good practice.
Step 1 - Clean up
If you have been trying lots of different, potentially incompatible, methods to get OpenMP set up, it is probably a good idea to clean them up first. So, something like:
brew rm --force gcc # or maybe gcc#4.9
Step 2 - Update Xcode and Command Line Tools
If you have upgraded macOS since installing Xcode, it is probably advisable to update Xcode and its "Command Line Tools"
Consider uninstalling and re-installing Xcode - it is available for free from the App Store.
Update/install the "Command Line Tools" after installing/updating with:
xcode-select --install
Step 3 - Install gcc
Now, try installing gcc afresh, ensuring that you use the --without-multilib option:
brew install gcc#4.9 --without-multilib
Hopefully you can now compile OpenMP code with:
/usr/local/bin/gcc -fopenmp program.c -o program
I am unsure exactly why the --without-multilib option is needed and prefer to quote #hristo-iliev:
Multilib usually refers to the coexistence of both 64-bit and 32-bit
versions of each library so that 32-bit software could be run on
64-bit OS. In the GCC case that probably refers to having all GCC
runtime libraries in "fat" Mach-O format, i.e. versions for both i386
and x86_64 in the same shared library file. It could be that libgomp
(the GNU OpenMP runtime library) cannot be built in such a way.
See this question.
Keywords: gcc, g++, GNU Compiler, OpenMP, fopenmp, -fopenmp, Xcode, multilib, Command Line Tools, macOS, OSX, homebrew, brew
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 was trying to use the omh.h header file and I realized it was missing. I tried reinstalling gcc on my mac using brew. This is the message I got at the end of the installation.
..
GCC has been built with multilib support. Notably, OpenMP may not work:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670
If you need OpenMP support you may want to
brew reinstall gcc --without-multilib
==> Summary
🍺 /usr/local/Cellar/gcc/4.9.2_1: 1156 files, 203M
It suggests that if I need OpenMP support I need to install brew reinstall gcc --without-multilib. I am not able to understand the meaning of --without-multilib. How is it different from simply installing gcc?
And apparently brew reinstall gcc --without-multilib takes forever to run and brew uninstall gcc && brew install gcc was lightning fast.
Multilib means support for multiple architectures, so you can compile binaries for them.
Given the bug you show, you should be safe as long you build binaries for AMD64 architecture (64-bit) and IA32, as that is what your machine is.
Otherwise, better to choose without multilib.