GHC now (since 8.10.5) supports producing ARM code on macOS.
What flags or options in GHC or Stack do I need to use in order for it to produce ARM executables?
Context: I have an Apple silicon Mac. It can run x86_64 code via Rosetta but it can also run native ARM code.
I will avoid discussing cross-compilation, since I don't think it is necessary.
For versions below GHC 9.2, you need to pass -fllvm in ghc-options. This is because GHC didn't include a Native Code Generator for the M1 yet. The Stack guide has a section on using ghc-options. You can set them globally, or you can set them for a narrower scope. You can try stack repl --resolver lts-19.1 --ghc-options -fllvm in your project to see if its dependencies are compatible with GHC 9.0.2, which is what LTS 19.1 uses.
For versions GHC 9.2+, GHC has a Native Code Generator such that it can compile for the M1 without LLVM. This should just work, with no need to pass any special ghc-options.
Make sure you are using Stack v2.7.5+, because this version added support for installing GHC on macOS aarch64 (which is what the M1 is). See the changelog. You can upgrade Stack using stack upgrade.
Stack v2.7.5 hasn't been tested with versions above GHC 9.0 though, so you may want to use Cabal instead, if you choose to use GHC 9.2+. See this snippet:
$ stack repl --compiler ghc-9.2.2
Stack has not been tested with GHC versions above 9.0, and using 9.2.2, this may fail
Related
I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).
I have been tweaking GCC 6.3.0 to get it to use the libc++ runtime instead of libstdc++ so that g++ can be used without worrying about C++ runtime incompatibilities:
https://github.com/RJVB/macstrop/tree/master/lang/gcc6
The tweak works, I can build and run KDE software using g++ against Qt5 and KF5 frameworks (and everything else) built with various clang versions.
What doesn't work is generating code that uses AVX and presumably most or all newer intrinsic instructions.
This is not a new issue that's never been invoked on here; it's answered here for instance: How to use AVX/pclmulqdq on Mac OS X
Evidently one can configure gcc to call the linked script instead of the actual as executable.
But can gcc not be configured to use another assembler altogether, like nasm, and would that solve this issue?
The question is about a specific combination of versions but is relevant more generally.
I've just dist-upgraded from Kubuntu 12.04 to 14.04. Now, when I want to compile CUDA code (with CUDA 6.5), I get:
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
I installed gcc-4.8 (and 4.7), and tried to use the symlinks-in-/usr/local/cuda/bin solution suggested here:
CUDA incompatible with my gcc version
but this doesn't work. What should I do?
This solution is relevant to multiple combinations of CUDA and GCC versions.
You can tell CUDA's nvcc to use a specific version of gcc. So, suppose you want gcc 4.7 for use with CUDA 6. You run:
sudo apt-get install gcc-4.7 g++-4.7
and then add the following switch to your nvcc command-line:
nvcc --compiler-bindir /usr/bin/gcc-4.7 # rest of the command line here
If you're building with CMake, add an appropriate setting before looking for CUDA to your CMakeLists.txt, e.g.:
set(CUDA_HOST_COMPILER /usr/bin/gcc-4.7) # -> ADD THIS LINE <-
find_package(CUDA)
Also, it seems clang can compile CUDA as well, maybe that's worth experimenting with (although you would have to build it appropriately).
Note: Some Linux (or other OS) distributions don't have packages for multiple versions of gcc (in the same release of the OS distribution). I would advise against trying to install a package from another release of the distribution on an older release, and consider building gcc instead. That's not entirely trivial but it is quite doable - and of course, it's your only option if you don't have root access to your machine.
Switch back to a supported config. They are listed in the getting started document for any recent CUDA distribution.
For your particular configuration you have currently listed, you might have better luck with CUDA 7 RC, which is now available to registered developers.
I had a similar issue with CUDA Toolkit 7.5 and gcc 5.2.1.
I did modify the host_config.h file in /usr/local/cuda/include/:
Just remove the lines where it check the gcc version. It did solve my problem.
Credits goes to Darren Garvey (https://groups.google.com/forum/#!topic/torch7/WaNmWZqMnzw)
Very often you will find that CUDA has had newer releases by the time you encounter this problem. For example, the original formulation of the question was about CUDA 6 and GCC 4.9; CUDA 7 supported GCC 4.9. CUDA 8 supports GCC 5.x . And so on.
I've been trying to find an answer to this on stackoverflow for about an hour now, seems that a lot of similar problems are around but none really fitting to mine.
Information about what tools I'm using can be found further down!
I am writing my own compiler for a subset of the java language and thus creating assembler code. Now I'm at a point where I need to debug said assembler code to locate a bug. The problem is when I compile my assembler code to a binary with gcc -m32 -g myAssembler.s I get the following warning:
warning: no debug symbols in executable (-arch i386)
(This warning also occurs using -ggdb, -ggdb2, -ggdb3, -g2, -g3instead of -g
Since there are no debug symbols I can't use gdb to debug my code. I don't know much about linking and how it's done or who does it (especially on a Mac), so precise/noob-friendly answers would be very welcome.
Tools I'm using:
The assembly created from my compiler is x86, 32-bit GAS Syntax.
I am using OS X Mavericks with GNU gdb (GDB) 7.6 downloaded via MacPorts (They changed its name to ggdb. The ggdb --version command shows also a line saying :
This GDB was configured as "x86_64-apple-darwin13.0.0".
(Not quite sure if that's important.)
Running gcc --version returns:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
This is probably connected with Apple dropping support for GDB in Xcode 5 and you are using the version of gcc that comes with Xcode 5. You probably need to change compiler or debugger (to lldb)… you might look at llvm-gcc (which Xcode 5 also drops support for). Try www.llvm.org for a download. But that might be more trouble than using lldb (if your problem is indeed connected to Xcode 5's changes). Good luck! – CRD
I just downloaded gcc-4.2 from homebrew and that seems to work for lldb (which is still supported by Xcode 5 it seems). – Octoshape
I have just upgraded to OS X 10.8 "Mountain Lion" and I start regretting having done that.
I am no longer able to build my (simple) parallel code that uses OpenMP.
By looking here and there I understood that Apple is no more using 'gcc' but 'llvm' - quite likely due to licence-related issues. Unfortunately 'llvm' does not (yet?) support OpenMP.
I cannot believe many programs based on OpenMP will not run any more on OS X, so my question is: how can I enable OpenMP in Mountain Lion?
After reading the excellent answer of Hristo Iliev, I think I missing more than I initially thought.
I am not using XCode. The building is based on CMake and make/gcc. Yesterday I installed gcc 4.2 via macports, but - as of today - my code is still in source form because - for some strange reasons - I am not able to switch the compilation to gcc (same errors related to OpenMP).
The problem now is that CMake keeps using the llvm compiler.
In the root CMakeLists.txt I added the following two lines:
set(CMAKE_C_COMPILER "/opt/local/bin/gcc-apple-4.2")
set(CMAKE_CXX_COMPILER "/opt/local/bin/gcc-apple-4.2")
and I also added two environments variables:
export CXX=/opt/local/bin/gcc-apple-4.2
export CC=/opt/local/bin/gcc-apple-4.2
When CMake tries to find OpenMP ( FIND_PACKAGE(OpenMP) ) I get the following output:
-- The compiler is /opt/local/bin/gcc-apple-4.2
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Failed
[...]
CMake Error at /opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find OpenMP (missing: OpenMP_C_FLAGS OpenMP_CXX_FLAGS)
Call Stack (most recent call first):
/opt/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
/opt/local/share/cmake-2.8/Modules/FindOpenMP.cmake:159 (find_package_handle_standard_args)
demo/CMakeLists.txt:8 (FIND_PACKAGE)
I tried to run /opt/local/bin/gcc-apple-4.2 manually and it fails due to a missing libgomp.
Regards
LLVM is a compiler framework that Apple uses extensively in OS X (most notably in the OpenGL implementation), not a compiler itself. There are two LLVM frontends available in Xcode - the old GCC-based one llvm-gcc (which supports OpenMP 2.5) and the new clang (which does not support OpenMP). clang has extensive static code analysis capabilities and also much nicer error reporting, especially with C++ code. Mostly that's the reason Apple is investing in it and moving away from GCC (the FreeBSD project, on the other side, is seeking to replace GCC with clang for purely license-related reasons). There is an ongoing project clomp (not to be mistaken with Intel's Cluster OpenMP) that seeks to create an OpenMP-aware version of clang, but it is far from mature.
If you do not need new OpenMP constructs like explicit tasks and can live with some bugs, you can still use the old GCC frontend. Just switch the compiler suite in the project settings to LLVM GCC 4.2:
This one is based on the really ancient GCC 4.2.1 and no longer seems to be developed. Should you need a newer version of GCC, simply build one. Unfortunately I cannot provide you with information on how to integrate it into Xcode. It works for me on the command line with GCC 4.7.1 and OS X 10.8.2 (and I don't use Xcode much).
Just adding few words to excellent Hristo's answer: you can install gcc via MacPorts. This is much simpler than compiling everything by hands (and compiling gcc from scratch might be really non-trivial task due to dependencies, etc).
So, install MacPorts, do "sudo port install gcc47", wait few hours and you'll end with gcc-mp-4.7 which is able to compile your OpenMP code.