I want to write parallel program in C++ using OpenMP, so I am getting started with OpenMP.
On the other words I am a beginner and I need good OpenMP guide telling how to install it.
Does someone know how to install OpenMP on Windows, then compile and run the program?
OpenMP is not something that you install. It comes with your compiler. You just need a decent compiler that supports OpenMP and you need to know how to enable OpenMP support since it is usually disabled by default.
The standard compiler for Windows comes from Microsoft and it is the Microsoft Visual C/C++ compiler from Visual Studio. Unfortunately its OpenMP support is a bit outdated - even the latest and greatest Visual Studio only supports OpenMP 2.0 (an outdated standard version from 2002). See here for more information on how to use OpenMP in Visual Studio. There are other compilers available as well - both Intel C/C++ Compiler (commercial license required) and GCC (freely available) support newer OpenMP versions and other compilers are available too.
You can start learning OpenMP by visiting the OpenMP web site here. Also there is a great tutorial on OpenMP from Lawrence Livermore National Laboratory available here.
2020 Update: Microsoft now ships Clang for Windows with Visual Studio. Although it is a bit convoluted, one can (ab)use the Clang-cl toolset to produce working 32-bit OpenMP programs. A number of steps are necessary:
If not already installed, add Clang and Clang-cl using the Visual Studio 2019 Installer.
Set the project's platform toolset (project Properties -> General -> Platform Toolset) to "LLVM (clang-cl)".
Enable Clang OpenMP support by adding -Xclang -fopenmp to the compiler options in project Properties -> C/C++ -> All Options -> Additional Options.Important: make sure that OpenMP support is disabled before switching the platform toolset (this is the default for new C++ projects). It seems that VS remembers the setting and still passes /openmp even though the language configuration for Clang has no option for OpenMP. If clang-cl.exe throws error MSB8055 (unsupported /openmp option) during build, set the platform toolset back to "Visual Studio 2019 (vXXX)" and disable the OpenMP support in Properties -> C/C++ -> Language -> Open MP Support, then switch the platform toolset again to "LLVM (Clang-cl)".
Add libomp.lib to the additional libraries in project Properties -> Linker -> Input -> Additional Dependencies.
Add the path to libomp.lib to the linker search path by adding a new entry with value $(LLVMInstallDir)\lib in project Properties -> Linker -> General -> Additional Library Directories.
Add a post-build action that copies LLVM's libomp.dll to the project output directory (without this step, running the executable will fail unless libomp.dll is in the DLL search path). In project Properties -> Build Events -> Post-Build Event -> Command Line:
xcopy /y "$(LLVMInstallDir)\bin\libomp.dll" "$(SolutionDir)$(Configuration)"
Build and run the project.
Note: this is very much likely still unsupported by Microsoft and it only works for x86 projects since the LLVM libraries shipped with VS are 32-bit only.
So here is what I did to finally get OpenMP working on my Windows 10 PC:
Get MinGW - Download and grab what you need to get the basic gcc compiler and the g++ pakage (its really easy to do). You can always run g++ -v to make sure it is up and running
Run mingw-get upgrade --recursive "gcc<4.7.*" "gcc-g++<4.7.*" This is the "Fun" part. Because at this time there was no libgomp library supported in their 4.9.* version my gcc wasn't able to recognize <omp.h> the last support version was 4.7.2 so with this I finally was able to run my openMP
To compile run g++ -fopenmp myOpenMPFile.cpp -o myOpenMP and it will all work from there
gcc -fopenmp myOpenMPFile.cpp -o myOpenMP will also work for C code
I would like to share what I did to get OpenMP working on my Windows 10 PC (things have got even simpler in 2019)
I installed MinGW distribution from here with GCC 8.2.0 compiler. The maintainer of the distribution has already added winpthreads and OpenMP support to GCC.
I compiled my code with -fopenmp flag as follows: g++ -fopenmp main.cpp -o exec
Note: the MinGW distribution provides support for many useful libraries (such as Boost 1.69.0) and other utilities. I found it to be very useful.
Related
I'm having a hard time cross-compiling an embedded Rust project for Cortex-M4 in Windows. Going through the Embedded Rust book, I understood that it is needed to install the necessary target and toolchain. I'm trying to do this as follows (in a Windows cmd session):
> rustup target add thumbv7em-none-eabihf
info: component 'rust-std' for target 'thumbv7em-none-eabihf' is up to date
> rustup toolchain install stable-thumbv7em-none-eabihf
info: syncing channel updates for 'stable-thumbv7em-none-eabihf'
info: latest update on 2021-05-10, rust version 1.52.1 (9bc8c42bb 2021-05-09)
error: target 'thumbv7em-none-eabihf' not found in channel. Perhaps check https://doc.rust-
lang.org/nightly/rustc/platform-support.html for available targets
I do not understand the above error message. I have checked the provided link, and it seems that cortex-m4 is a "tier 2" target. I am suspicious that I have used the wrong toolchain prefix, e.g. "stable"?
Of course, if I skip the above and try to build the project with cargo build, it fails while looking for the wrong linker executable, i.e.:
error: linker `link.exe` not found
|
= note: The system cannot find the file specified. (os error 2)
note: the msvc targets depend on the msvc linker but `link.exe` was not found
note: please ensure that VS 2013, VS 2015, VS 2017 or VS 2019 was installed with the Visual C++ option
As a side note, the project builds fine on Linux and Macos.
Could someone shed some light on how to set up the toolchain and target correctly? Unfortunately, the Embedded Rust book does not dive into OS-specific toolchain installation.
To build a C library with Visual Studio, the CMake command
set(WINDOWS_EXPORT_ALL_SYMBOLS ON)
saves me from adding __declspec(dllexport) or __declspec(dllimport) in front of function declarations; explicit import/export symbols are only required for global variables.
Under MinGW (read: either MinGW or its recommendable replacement Mingw-w64) this does not work. Linking applications (also built with MinGW) to my library failed until I had pasted import/export symbols in front of each function. Whereas the long answer https://stackoverflow.com/a/32284832/1017348 suggests the contrary: no need for import/export symbols under MinGW. Is that answer right? How then to get rid of the need for import/export symbols?
I just encountered the same problem. After poking through CMake source code, the fix that worked for me was to also add:
set( CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS 1 )
CMake says:
This property is implemented only for MS-compatible tools on Windows.
CMake enables this capability by setting CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS in each "Platform" file in <cmake install>/Modules/Platform that they know supports it. However, CMake doesn't model MinGW as a "Platform". Instead you just pick "Windows Makefile", "Windows Ninja", etc. and manually set the C/C++/Fortran compilers to point to the MinGW gcc compilers. Ideally CMake should recognize when the OS is Windows and the compiler is gcc and set this for us, but for now we can help it by setting it ourselves.
Incidentally CMake implements this feature with a hidden cmake -E __create_def <output-def> <input-list-of-obj-files> command. I previously thought of adding a custom rule to run that command. Though as it starts with __, it's meant for internal use and might change from one release to the next.
I'm currently working on a C++ project that build successfully on Linux using CMake, Make & GCC, and also on Windows using CMake & VS2015.
For some reason, i'd like to build it using the same toolchain everywhere, so i planned to use CMake, Clang & Ninja.
I started to try to build it on Windows, but i did not find any documentation to build using libc++ and without anything from the MSVC toolchain.
Am I forced to install MSVC build tools in order to build with CMake & Clang ?
Use a MinGW-w64 of GCC on Windows (e.g. the one from http://winlibs.com, or any other one listed at http://mingw-w64.org/).
If you combine this with the MSYS2 shell (http://www.msys2.org/), you can build a lot using the same tools as on Linux (autoconf, CMake, meson, ...).
According to LLVM's Getting Started (Windows) site:
... Clang can be used to emit bitcode, directly emit object files or even linked executables using Visual Studio’s link.exe.
Why is the use of Link.exe on Windows necessary? And, for that matter, what is used on Mac/Linux? Further down it says:
Compile the program to object code using the LLC code generator:
C:\..> llc -filetype=obj hello.bc
Link to binary using Microsoft link:
C:\..> link hello.obj -defaultlib:libcmt
Why can't LLC perform that last step? LLI seems to work fine so I assume that it interoperates with link.exe somehow under the hood - why can't LLC?
Because no one has written a linker for LLVM.
There is a project to do so (called, unimaginatively lld) but it's not ready yet.
See http://lld.llvm.org for more details.
On the mac, people use Apple's linker, ld.
On Linux, most people use the gnu linker, usually (also) named ld
Try MinGW-W64's ld. I've been using it with llvm's clang instead of VS tools that I used for building clang in the first place.
When building Boost binary libraries with bjam, one may specify which compiler to use, without specifying a particular compiler version, by using certain values for the --toolset= option. For example:
bjam --with-serialization --toolset=msvc
the toolset value msvc tells bjam to search your system for some version of Microsoft Visual C++ and then use it to build a number of variants of the Boost.Serialization library. The resulting libraries will contain a tag indicating which toolset was actually used. For example, the above command creates files such as:
libboost_serialization-vc100-mt-s-1_44.lib
libboost_serialization-vc100-mt-sgd-1_44.lib
...
where the string vc100 in the filename is a toolset tag indicating that the Microsoft Visual C++ 2010 compiler version was found and used to build the libraries. [More details about Boost library file naming conventions can be found here.]
One may specify also a specific version of a compiler using certain other values for the --toolset= option. For example:
bjam --with-serialization --toolset=msvc-9.0
tells bjam that, even though I may have several compilers on my system, I want it to specifically use Microsoft Visual C++ 2008. The resulting libraries contain the tag string vc90 to indicate that Microsoft Visual C++ 2008 was used to build them.
The Boost documentation seems to be a bit out-of-date with respect to newer compilers on the Mac (e.g., how does one distinguish between GCC, LLVM-GCC and LLVM?)
My question is, what are some of the other bjam --toolset= values and their corresponding tags for specific compiler versions in Xcode 3 and Xcode 4 on the Mac (not the general compiler name values like darwin)? Are these documented anywhere? Even if building Boost libraries with some versions is not yet supported by Boost, have the toolset and tag values been specified yet?
Please help replace the ???s in this table:
TOOL AND VERSION --toolset= TAG
======================================================
Microsoft Visual C++ 2008 msvc-9.0 vc90
Microsoft Visual C++ 2010 msvc-10.0 vc100
Apple (1) GCC 4.0 (2) ??? xgcc40
Apple GCC 4.2 ??? xgcc42
Apple LLVM GCC 4.2 ??? ???
Apple LLVM compiler 1.5 (2) ??? ???
Apple LLVM compiler 2.0 (3) ??? ???
(1) Apple produces their own versions of the GCC and LLVM compilers to add Apple-specific extensions and behavior.
(2) Available in Xcode 3 only.
(3) Available in Xcode 4 only.
There is a direct mapping from the toolset specified to the base part of the tag. Hence for any Apple Xcode compiler that you specify that uses the darwin.jam toolset the start of the tag will always be xgcc (for Xcode GCC). The second part, i.e the version number of the compiler, is usually automatically discovered from the compiler itself. The darwin.jam toolset code uses the -dumnpversion option to discover what that version is (see darwin.jam line #123). So a few things:
For Xcode it will always be toolset=darwin for the default g++.
For other non-default versions you have to set up a site-config.jam or user-config.jam to tell Boost Build where and which are the compilers you have (see the BB Configuration docs).
The toolset=darwin-<some_version> matches what you specify in your configuration.
The darwin.jam toolset supports smart selection of the compiler based on what you are trying to build to make it a bit easier.
For example I use something like the following for iOS development:
using darwin : : /Xcode-path/usr/bin/g++-4.0 ;
using darwin : : /Xcode-path/usr/bin/g++-4.2 ;
using darwin : 4.2~iphone
: /Xcode-path/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -arch armv6
: <striper>
: <architecture>arm <target-os>iphone
;
using darwin : 4.2~iphonesim
: /Xcode-path/Platforms/iPhoneSimulator.platform/Developer/usr/bin/g++-4.2
: <striper>
: <architecture>x86 <target-os>iphone
;
For which I can:
bjam toolset=darwin-4.0 -- For a regular OSX build with GCC 4.0. Which results in the tag xgcc-42.
bjam toolset=darwin-4.2 -- Similarly for OSX and GCC 4.2. For which I would get a tag of xgcc-42.
bjam toolset-darwin architecture=arm target-os=iphone -- To do an iPhone device build with GCC 4.2. The tag ends up also being xgcc42 which is a collision. But there's a limit to how much we can account for in those tags. And it's usually not a problem because one segregates built results across platforms anyway.
You might set up using one of the LLVM compilers by adding to your configuration:
using darwin : 4.2~llvm~gcc : /Xcode-path/user/bin/llvm-g++ ;
And invoke with bjam toolset=darwin-4.2~llvm~gcc. Unfortunately the tag would also be xgcc-4.2 (as again, it's based on using darwin.jam). So you would need to segregate the resulting libs from the other GCC builds.
Also unfortunate is that there isn't a documented location of mapping the toolset used to the tag value other than in code (see the BB common.jam lines #801 to #841).