Is there any difference between g++ and gcc -lstdc++?
That is, is g++ just gcc with the C++ standard library linked by default?
g++ is a compiler, like gcc. g++ however includes the ability to parse modern C++ constructs, whereas gcc can do some of these, but is not intended for it.
-lstdc++ and gcc allows the compilation of libraries that use c++ specific runtime interfaces with your C code (gcc).
An example of this is a C application that needs to use a C++ library without needing to completely remake the C application into a C++ one to interface with it.
Related
I'm using the GNU Arm Embedded Toolchain to cross-compile on Windows, and was wondering what the following highlighted executables were used for. There are already arm-none-eabi-gcc and arm-none-eabi-g++ for compiling C and C++ code respectively, so I'm guessing arm-none-eabi-c++ and arm-none-eabi-cpp handle some sort of C++ pre-processing or linking of C++ libraries?
c++ is the common "standard" name for a C++ compiler. It's the same as g++.
cpp runs the preprocessor only.
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
I am currently porting my compiler from AIX XLC compiler to GCC compiler on AIX.
I want to know if there is an GCC equivalent compiler option available for the -qthreaded (XLC).
-pthread is the closest GCC option for use cases where -qthreaded is applied for XL; however, it is not equivalent to the -qthreaded option for IBM XL.
The GCC documentation for -pthread merely states that it sets macros (http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-pthread) and modifies the link step (http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-pthread-1). -qthreaded does not cause _THREAD_SAFE to be defined as a macro, nor does it cause -lpthreads to be present in the link step. GCC's -pthread is more like XL's _r invocations (which does set the macro and modify the link step).
What -qthreaded does is to disable optimizations that are unsafe for multithreaded programs. It appears that, at least historically, -fno-tree-loop-if-convert-stores would at least partially be a GCC equivalent to -qthreaded.
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.
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.