I'm using the Windows version of Clang (LLVM) 8 under Windows.
I'm compiling a code which uses OpenMP.
Under the lib folder of Clang there are 2 files which are OpenMP related:
libomp.lib.
libiomp5md.dll.
My questions are:
When I compile the code I use the flags -Xclang -fopenmp for the compiler. In in GCC and ICC using the flags tell the compiler to link the OpenMP library automatically. What about Clang? Does it do it automatically or must I link with libomp.lib manually? Is there a way to trigger automatic linking to the OpenMP library?
Answer: This was answered in Michael Klemm's answer below - Use the clang driver both for compiling and linking and then the -fopenmp will work as in GCC.
When I link with libomp.lib manually (Defining as a library for the linker) the output exe requires libomp.dll while the supplied OpenMP Dynamic Library is libiomp5md.dll. Is that a bug or is it because I link manually?
Answer: The libomp.dll is supplied in the bin folder and not the lib folder.
What's the proper way to utilize OpenMP in Clang under Windows? The clang-cl driver doesn't work with /openmp or -openmp as the MSVC's cl compiler.
Answer: Currently it can be done either with clang -fopenmp ..., clang-cl -Xclang -fopenmp ... or clang-cl /clang:-fopenmp ... (Which is equivalent of -Xclang -fopenmp).
Remark
On Windows I use Windows Driver of Clang using clang-cl.
Adding clarity to what the OpenMP libraries actually are, and how to use them on Windows with clang-cl
libomp.dll and libiomp5md.dll ARE THE SAME FILES!
When compiling for Windows, you link against libomp.lib OR libiomp5md.lib which will link to the same-named DLL at runtime, i.e. libomp.dll OR libiomp5md.dll respectively.
If you load 2 files that use the "different-name DLL," the interpreter will crash and give you a nasty error like: OMP: Error #15: Initializing libiomp5md.dll, but found libomp.dll already initialized.
Why? Because the program has no idea they are the same DLL, they have different names, so it assumes they are different. And it crashes. For this reason only, you can choose to swap which OpenMP DLL you link to in your program.
If your program doesn't crash and give you an error, you can keep using the same link to OpenMP. Otherwise, to silence the error, link to the one that is loaded by another program already.
If using clang-cl.exe which is the "drop-in" Clang replacement for MSVC cl.exe you should pass a compiler argument such as -Xclang -fopenmp which will convert the argument over to "Clang language." Don't forget to still pass to the linker the OpenMP LIB you chose, because on Windows, it won't be automatic.
That's all I've learned as brief as possible about OpenMP linking on Windows.
To compile and link OpenMP code with clang on Windows, you will have to pass -fopenmp to both the compiler and the linker:
clang -fopenmp -o bla.obj -c bla.c
clang -fopenmp -o bla.exe bla.obj
Related
Is it possible (within reason) to build a "toy" OS on a mac using llmv/clang (and the other "normal" build tools)? By "toy" OS, I mean the simple, "Hello, World" examples found on OSDev (http://wiki.osdev.org/Bare_Bones) and x86 Bare Metal (https://github.com/cirosantilli/x86-bare-metal-examples).
My main problem is I can't figure out how to specify precisely where the linker should place the code (i.e., that the starting point should be 0x7c00, that bytes 510 and 511 need to be 0xaa55, etc.).
I would say yes it is possible within reason, at least if you consider waiting for a build of lld (and its dependency llvm) reasonable. Instructions to build lld can be found on their website or as part of this answer.
Compiling and linking for a different target than the host is relatively easy with clang. You just have to set a target, for example -target i386-none-elf for an ELF binary. Cross-compilation using clang is explained in more detail here.
As for macOS, as Micheal Petch noted, you have to use another linker than the standard ld installed. You could in theory install binutils to get an ELF ld but then you have to compile it yourself to set the target. My recommendation is to use lld which can target many architectures without the need to recompile.
With clang and a lld in place we can compile sources with
clang -c -o file.o file.c -target i386-none-elf # freestanding flags omitted
and then link them with
clang -o kernel.bin file.o -target i386-linux-elf -nostdlib -Wl,linkerscript.ld -fuse-ld=lld
Note that for linking I am using i386-linux-elf because there is a bug in clang where they just forward their input to gcc. But when using -nostdlib it is essentially the same.
If you want to see a complete example ready to build, you can take a look at https://github.com/Henje/x86-Toy-OS.
I am currently trying to compile libxml2 on Solaris. When I run the ./configure script provided with the sources, the gcc and g++ compilers are automatically used. However, I would like to use cc and CC compilers. So I run :
./configure CC=cc CXX=CC
It works but then, when I run "make", I get some errors which prevent the libraries to be generated.
When gcc and g++ are used, everything goes well with no errors, so I was wondering: can I use the librairies generated with gcc/g++ the same way I would have used them if I had successively generated them with cc/CC?
What are the differences between a lib generated with cc and the same lib generated with gcc on Solaris?
You can use either the gcc or cc C compilers pretty much interchangeably.
You can mix the g++ and CC C++ compilers in certain ways, but only on x86 Solaris and if your CC compiler is new enough to have the -compat=g option available.
The GNU g++ and the Solaris Studio CC C++ compilers default to completely different ABIs and C++ run-time libraries. On x86 Solaris platforms, newer versions (since version 12.?, if I remember correctly) provide a -compat=g option to use the g++ ABI and run-time libraries. The Studio 12.4 CC compiler adds a -std=v option to select different versions of the g++ or Sun C++ ABI and run-time libraries:
c++03 (zero-3, not oh-3)
Equivalent to the -compat=g option. It selects C++ 03 dialect and g++ ABI; it is binary compatible with g++ on Solaris and Linux It
sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
c++11
Selects C++ 11 dialect and g++ binary compatibility. It sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
c++0x (zero-x, not oh-x)
Equivalent to c++11.
and
The -std=c++03 provides compatibility with the gcc/g++ compiler on
all Oracle Solaris and Linux platforms.
With -std=c++03, binary compatibility extends only to shared
(dynamic or .so) libraries, not to individual .o files or archive (.a)
libraries. The gcc headers and libraries used are those provided with
the compiler, rather than the version of gcc installed on the system.
Note that the Studio 12.4 CC compiler uses the g++ headers and libraries supplied bundled with the CC compiler itself. 12.3 and earlier use the g++ headers and libraries installed on the system under /usr/sfw.
On SPARC Solaris, you have to use either g++ or CC for the entire application.
I've recently downloaded CUDA 7 and set it up to work with my project. On Mac, CUDA 7 requires clang to be the host compiler.
Now, I'm using a number of C++11 features. I've enabled these with -std=c++11 passed to nvcc this works. However, if I pass -Xcompiler -std=c++11 to nvcc, I get the following error regardless of if I also passed -std=c++11 by itself. The error is:
"invalid argument '-std=c++11' not allowed with 'C/ObjC'"
It seems like this should work, it certainly does with GCC. Anyone have a workaround. Otherwise, I'll file a bug report with Nvidia.
nvcc -dryrun ... will show what commands nvcc will execute. I don't currently have access to CUDA 7, only 6.5, but mine issues, among other things, two commands that compiles generated C source. This code generated by cudafe and have to be compiled by C compiler, but -Xcompiler adds options for both C and C++ modes.
I guess difference with my gcc situation is that I'm getting a warning while you have an error (this is exactly how gcc and clang differs in that case). For both compilers I don't see any way to suppress it, so I guess you have to fix your .cmake files to omit -Xcompiler options. This options shouldn't be used for language standard, just some very compiler-specific things.
Of course it doesn't work. You are specifying C++ options while using a C or Objective-C compiler. The source files must be C++ or Objective-C++.
I am compiling a third-part software, with mpif90, that in my case is the mpi version of gcc. The package comes with a makefile. After compiling the object files, the makefile creates the archive with ar, but this fails because there are not input object files. In effect I tried to compile by hand the object files (.o) with
mpif90 -lmkl_gf -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -openmp -O3 -DMPI -c a.f90
and the a.o is not created, a .mod file is created instead. I don't have much experience with fortran, and I am a bit puzzled, because the -c flag should create an object, shouldn' it?
I have verified that gfortran does create the object file if I remove the flag openmp
Notes:
mpif90 -v
gcc version 4.4.3
OS : Ubuntu 10.04.4 LTS
I changed the flag openmp to fopenmp
http://gcc.gnu.org/onlinedocs/gfortran/OpenMP.html
In case anyone comes across this question in the future ... the flags used by the OP are specific to the intel fortran compiler while it seems the mpif90 wrapper is using the gfortran compiler. The proper flag to use OpenMP with gfortran is -fopenmp and the library is -lgomp. It is possible to use the intel library with a different vendors compiler, but its easiest to stick with one vendor.
When running nvcc, it always uses the Visual C++ compiler (cl.exe). How can I make it use the GCC compiler?
Setting the CC environment-variable to gcc didn't fix it. I also couldn't find any option for this in the executeables help-output.
On Windows, NVCC only supports the Visual C++ compiler (cl.exe) for host compilation.
You can of course compile .cpp (non-CUDA) code using GCC and link the objects with objects generated by nvcc.