where can i find informations who the g++ compiler mangle names?
e.g. i see when i have a function with two int the symbol always have the ending "ii" but is this always so? i need to get some documentation
G++ uses the IA64 C++ ABI mangling specification.
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling
Related
I'm working on a CMake-based project that contains both C++ and CUDA source files, and has some headers meant to be included by both languages.
For these header files, I'd like to see the result of highlighting and syntax checking as close as possible to what NVCC, the CUDA compiler, would see, so for example, I'd like to have the preprocessor symbol __CUDACC__ be defined.
It's important to me that CMake does not have such a symbol defined, because it's really an internal symbol of the NVCC toolchain that I need for syntax-checking purposes.
I've tried "Tools->C++->Additional preprocessor directives" and it seems to have no effect. I've also tried a file named CMakeLists.txt.config which seems to have no effect either.
I'd love a suggestion for this.
To reiterate, I'm looking for a way to set a define (CPP symbol) visible to to the syntax-checking system only.
After further digging I found an attribute specific to the Clang analyzer that is defined during the analysis performed for syntax checking but not during compilation.
Note that this is purely because my project compiles with GCC, while QT Creator's syntax checking runs through Clang.
// GCC and NVCC don't have __has_feature(), so we provide a fallback
#ifndef __has_feature
# define __has_feature(x) 0
#endif
#if __has_feature(attribute_analyzer_noreturn)
# define IN_CLANG_ANALYZER 1
#else
# define IN_CLANG_ANALYZER 0
#endif
This allows a clumsy hack as follows, which may or may not be useful, depending on one's needs. Pretty much the idea is that much like you'd
have Clang observe your code even if you compile with GCC, this achieves
something similar for files inteded to be used with NVCC.
#if IN_CLANG_ANALYZER and !defined(__CUDACC__)
# define __CUDACC__
# include <cuda_device_runtime_api.h>
# include <optix_device.h>
#endif
However the substantial problem remains that when compiling with Clang, all the above falls flat on its face, because clang++, the compiler, also defines the same feature as enabled.
What's needed to fix this is some kind of macro defined in the analyzer but not in Clang, and so far I've found none like this.
At first I had hoped __clang_analyzer__ would fit this need,
but according to my version of Qt Creator (6.0.2) the macro is not defined
during syntax checking, so we're back to square one.
I am using Clion which uses Cmake which uses a CMakeLists.txt that looks like this:
cmake_minimum_required(VERSION 3.3)
project(Thesis)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c99")
set(SOURCE_FILES main.cpp graph.h graph.c shared.h shared.c)
add_executable(Thesis ${SOURCE_FILES})
I have been searching and searching for an explanation on -std=c99. The default was -std=c++11 and I changed it because I am writting a C program, by intuition, I didn't see that keyword anywhere, I just guessed it. However, I don't fully understand what this parameter does, and I want to. What other parameters can it take ?
Where is that documentation exactly ?
First of all. If you are writing a C program, name your files .c - not .cpp to be sure that CMake identifies them as C code. This is the reason you see -std=c++11 by default.
You can then use SET(CMAKE_C_FLAGS ...) to add compiler flags even though this isn't the recommended way. You shall never assume that GCC will be called.
As #zaufi said. You can use:
set_property(TARGET Thesis PROPERTY C_STANDARD 99)
https://cmake.org/cmake/help/v3.1/prop_tgt/C_STANDARD.html#prop_tgt:C_STANDARD
The -std flag is a GCC compiler flag that determine which language features GCC shall enable. Read more here:
http://linux.die.net/man/1/gcc
-std=
Determine the language standard.
This option is currently only supported when compiling C or C ++ .
The compiler can accept several base standards, such as c89 or c++98,
and GNU dialects of those standards, such as gnu89 or gnu++98. By
specifying a base standard, the compiler will accept all programs
following that standard and those using GNU extensions that do not
contradict it. For example, -std=c89 turns off certain features of
GCC that are incompatible with ISO C90, such as the "asm" and
"typeof" keywords, but not other GNU extensions that do not have a
meaning in ISO C90, such as omitting the middle term of a "?:"
expression. On the other hand, by specifying a GNU dialect of a
standard, all features the compiler support are enabled, even when
those features change the meaning of the base standard and some
strict-conforming programs may be rejected.
I'm using CMake for a moderate-sized Fortran project; sometimes I build it with gfortran, other times with ifort. When I want to do a debug build, the compiler flags are different; I'd like to have CMake automatically check which compiler is being used and set the flags accordingly.
It looks like this answer shows how to do the same thing for different C++ compilers. There's an example of how to check compilers with Fortran, using
if (Fortran_COMPILER_NAME MATCHES "gfortran.*")
However, this fails to invoke the conditional, because CMake has decided to use f95. Of course, f95 happens to alias to gfortran, but CMake doesn't detect that.
What's the right way to do this?
You can use also use CMAKE_Fortran_COMPILER_ID:
if ("${CMAKE_Fortran_COMPILER_ID}" MATCHES "Intel")
# something
elseif("${CMAKE_Fortran_COMPILER_ID}" MATCHES "GNU")
# something else
endif
Best way is to read file CMakeDetermineFortranCompiler.cmake and related files referenced from it.
Rather than trying to special case for different compilers you should actually test that your compiler supports the flags you want to set using check_fortran_compiler_flag like so:
include(CheckFortranCompilerFlag)
check_fortran_compiler_flag("-my-flag" _my_flag)
if(_my_flag)
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -my-flag")
endif()
This is both safer and (I think) simpler because you don't need the implied knowledge of which compiler (and version) supports which flag.
It's simple. Only indicate the full path of compiler installed e.g.gfortran. the code: cmake -DCMAKE_fortran_PATH=/usr/bin/gfortran
I haven't been able to find a list of possible values for the LANGUAGE variable on the CMAKE.org site or anywhere else. Would someone please enumerate the values CMAKE recognises? I specifically need to specify Objective C++.
Just take a look at all the CMakeDetermine<Language>Compiler.cmake scripts CMake ships with.
This would result - in alphabetic order - in the following you could put in the enable_language() call:
ASM
ASM-ATT
ASM-MASM
ASM-NASM
C
CSharp
CUDA
CXX
Fortran
Java
OBJC (Objective C)
OBJCXX (Objective C++)
RC (Windows Resource Compiler)
Swift
Evaluated with CMake Version 3.16
References
enable_language()
Generic rule from makefile to CMake
Update for CMake 3.16 and later: CMake added native support for Objective-C in version 3.16. The corresponding language strings are OBJC and OBJCXX. Thanks to squareskittles for pointing this out.
Original answer: The support for languages varies across platforms.
Currently CMake supports C, CXX and Fortran out of the box on most platforms. There is also support for certain Assemblers on some platforms. For a complete list, check out the contents of the Modules/Platform folder.
The idea is that the language given to the LANGUAGE field of the project command or the enable_language command is just a string, which will then be used by CMake together with the language dependent variables to setup the build system. The Platform scripts shipping with CMake do this configuration for C and C++. In theory, one can add their own language simply by setting the correct variables (although this is quite involved and I do not know of anyone ever successfully doing this).
As for adding support for Objective-C: Since most toolchains use the same compiler for C and Objective-C, you do not need to configure a new language. Simply compile your code as if it was plain C and add the appropriate compiler flags for Objective-C support.
Unfortunately, this is not very comfortable to use and can easily break in corner cases. But until CMake adds explicit support for Objective-C as a first class language, I'm afraid this is as good as it gets.
I am trying to link a statically created .a library with another piece of C code.
However, in the final executable several symbols (function names) are are found missing when seen with the nm command. This is due to the fact that the linker (gcc being called) is stripping the symbols which are not referenced in the other piece of C code that is being linked with the library. The function symbol that I am trying to find with the nm command is visible in the .a library.
How can I make the linker not strip the symbols omitted this way?
Compile in gcc with -dynamic to force the compiler to include all symbols. But make sure that's what you really want, since it's wasteful.
Might be useful for some static factory patterns.
Generally, the linker does strip out other symbols - mainly for
Reduce the final size of the executable
Speed up the execution of the program
There are two trains of thoughts here:
When you use the option -O as part of the gcc command line, that is optimizing the code and thus all debugging information gets stripped out, and hence the linker will automatically do the same.
When you use the option -g as part of the gcc command line, that includes all debugging information so that the executable can be loaded under the debugger with symbols intact.
In essence those two are mutually exclusive - you cannot have both combined.
So it depends on which switches did you use for this to happen. Usually, -g switch is for internal debugging and testing prior to public release. The opposite would be something like this -O2 which makes the compiler smart enough to generate a executable that would be considered optimized such as removing dead variables, unrolling loops and so on.
Hope this helps and gives you the hint
Normally you need to call some registration function in your application to generate such a reference. Of course if you don't have access to the code of the first library, you can only use the -g option as described by tommieb75.