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.
Related
I tried almost a hundred things to make this works but nothing seems to be working.
I recently acquire a Mac book pro M1 MAX (so arm64 architecture), system provided by default with clang g++.
I wanted to install boost library. Using homebrew the 1.80 version was installed but I need to work on a project with the 1.65.1 version (I tried compiling my project with 1.80 version and tons of undefined symbols and errors were raised from boost library even if I have all of them, so I'm guessing I need to install the exact same version required)
so I decided to build and compile boost by myself following the boost guide
https://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html
Following section 5.1 I tried to use the bootstrap script and this one fails using Darwin toolset. (apparently some Clang warning caused error). I resolve then by changing the boost source code like this :
https://github.com/boostorg/build/commit/48e9017139dd94446633480661e5447c7e0d8b1b
But there's still lot of issues during the compilation
I don't know what to do to be able to compile with clang, I don't even know if this will be compiled for arm64 architecture.
anyway I install gcc compiler and tried with gcc toolset.
./bootstrap --with-toolset=gcc
The bootstraps works but then running the b2 script cause a segmentation fault instantly and on every commands I tried (even the --help options raised an exception...).
Why is building boost so complicated on arm chipset ?
What can I do to build boost (either clang or gcc, arm or cross compiled universal library) ?
I'm desperate at this point.
Thanks for the help.
I tried everything
with clang (darwin)
with gcc
with options to add arm64 as architecture
changing the source code of boost to fix
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.
After hours of research (and tries) on how to install id3lib on Qt (windows), but with no success, I decided to use TagLib's library.
I followed this tutorial to build a compatible version of taglib for Qt but still another problem (full log here):
...
C:\MinGW\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: Dwarf
Error: found dwarf version '4', this reader only handles version 2 and 3
information.
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib/crt2.o:crt1.c:(.text+0x1f1):
undefined reference to `__chkstk_ms'
...
In CMake, I did configure > MinGW Makefiles.
Can anyone tell how to fix it?
Environment:
Windows 7 (64-bit);
CMake 2.8.12.1;
TagLib 1.9.1;
GCC 3.4.5;
Qt 5.1.1.
The problem stems from the fact that you are using terribly outdated GCC, while your Qt binaries are most likely built with bleeding-edge GCC (or the one close to it). For instance, as the error message shows, DWARF is outdated in case of your current GCC and is incompatible with the one used by your current Qt. Furthermore, even if it wouldn't, you'd still hit other problems with binary incompatibilities, since you essentially mix compilers with different major version numbers, which is strongly discouraged. Notice, that your problem has nothing to do with CMake at all. You can see it yourself in the error message, i.e. the error is reported by ld, the linker utility from (your outdated) GCC toolchain. To conclude, your only option is to update GCC, ideally exactly to the one which was used to build your current Qt.
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