My project is in C and shared library in C++ (I using Eclipse IDE on Linux platform). Default setting of project taking C compiler (GCC). Can anybody suggest me how to change compiler from C to C++ for my project.
GCC can compile both C and C++ source files. It uses filename extensions to determine if it should compile as C or C++.
C++ source files conventionally use one of the suffixes ‘.C’, ‘.cc’, ‘.cpp’, ‘.CPP’, ‘.c++’, ‘.cp’, or ‘.cxx’; C++ header files often use ‘.hh’, ‘.hpp’, ‘.H’, or (for shared template code) ‘.tcc’; and preprocessed C++ files use the suffix ‘.ii’. GCC recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name gcc).
GCC: GNU Compiler Collection
gcc: GNU C Compiler g++: GNU C++ Compiler
The main differences:
gcc will compile: .c/.cpp files as C and C++ respectively.
g++ will compile: .c/.cpp files but they will all be treated as C++ files.
Also if you use g++ to link the object files it automatically links in the std C++ libraries (gcc does not do this).
Related
I have been asked to compile C Source codes with g++ compiler in cMake environment.
I tried one of the solution from Stack Overflow:
Set CC,CXX before running cmake like in below steps.
export CC=/usr/bin/g++
export CXX=/usr/bin/g++
but I get below errors while running cmake
"cmake -DPLATFORM=x64 ../"
-- The C compiler identification is unknown
-- The CXX compiler identification is GNU 7.5.0
-- Check for working C compiler: /usr/bin/g++
-- Check for working C compiler: /usr/bin/g++ -- broken
CMake Error at /usr/share/cmake-3.10/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/usr/bin/g++"
is not able to compile a simple test program.
It fails with the following output:
For individual files you can set the language yourself independent of the file extension by setting the LANGUAGE source file property:
# compile foo.c and bar.c with the C++ compiler
set_source_files_properties(foo.c bar.c PROPERTIES LANGUAGE CXX)
This results in CMake using the C++ compiler for the .c files regardless of the compilers used for C / C++.
It may be possible to achieve the same effect for the whole project by listing only C++ as language, but I haven't tested this option:
# top level project
project(MyProject LANGUAGES CXX)
...
I'm trying to use the Mingw-w64 toolchain provided by LH_Mouse, version 10.2.1.
When compiling this small program:
#include <windows.h>
#include <stdio.h>
int wmain()
{
wprintf(L"Hello world!\n");
ExitProcess(0);
}
with the following command:
gcc.exe test.c -o test64.exe -municode -s -Os -Wall -nostdlib -lmsvcrt -lkernel32 -e wmain
I get an error: undefined reference to `__mingw_vfwprintf'
Z:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.1/../../../../x86_64-w64-mingw32/bin/ld.exe: R:\Temp\ccDSsj2M.o:test.c:(.text+0x3d): undefined reference to `__mingw_vfwprintf'
collect2.exe: error: ld returned 1 exit status
I previously used Mingw-w64 7.3.0 provided on SourceForge and everything worked fine.
Of course I can use the stdlib (and in this case there is no error) but this increases the size of the executable.
I have read that some changes have been done recently to support UCRT. Is it related?
Is there a way to use msvcrt like before?
Edit: using -lmingwex does not really help. If located after -lmsvcrt, it produces a huge amount of varied "undefined reference" errors. If located before, we got several "undefined reference" to ___chkstk_ms, and one to _pei386_runtime_relocator.
The first ones can be removed by adding -lgcc after -lmingwex. For the last "undefined reference", I have found nothing. Adding -lmingw32 does not help, no matter its location.
So for now, the only possibilities I see are to either modify stdio.h, or create my own declarations.
Well, I use mingw since many years and its not the biggest issue I encountered. But I am a bit disappointed that it affects such basic functions.
You are trying to compile your application with -nostdlib option which means that standard C functions (like printf, scanf, wprintf, ...) are not available for your application. Therefore you should not include standard C header files (like stdio.h, stdlib.h, ...) and also you should not use wprintf in your application.
If you really want to standard C function with -nostdlib option then you have to write your own C header files and also your own implementation of standard C functions (like wprintf).
What you did was to include MinGW's stdio.h header file which calls lot of standard C functions and also internal MinGW functions and then told gcc (via -nostdlib to not link these standard functions and neither internal MinGW functions. Which obviously resulted in lot of linker errors.
Then you have tried to manually link msvcrt.dll library but it failed too as this Windows library does not contain internal MinGW functions used in MinGW's stdio.h header file.
If you really want not use standard C functions from gcc/MinGW (via -nostdlib option) but rather directly via Windows msvcrt.dll library then you have to use also Windows stdio.h header file and not MinGW one. But beware that Windows header file stdio.h is not supported for gcc compiler and it also does not have to work.
So you should first answer questions, why you are trying to use standard C functions (like wprintf) without standard C library with gcc compiler? This sounds really strange and such thing is common only in freestanding environment or for bare-metal applications (like firmware, bootloader, kernel, ...). Are you workarounding some other bug which you have not mentioned?
And to answer your question, why in previous version it (probably) worked fine. Older version of gcc compiled C code according to C89 standard (with GCC extensions). New version of gcc started to compile C code according to C11 standard. Windows library msvcrt.dll provides only subset of standard C functions and only for C89 standard. For this reason MinGW provides its own implementation (or fixes) for some standard C functions to be compliant with C99 and C11 standards. As older gcc compiled your application as C89 code and manually linked msvcrt.dll library provided somehow compatible implementation for printf and wprintf, it resulted in final exe file without errors. Now with new gcc you are compiling your application as C11 code and you are trying to call C11 wprintf function but this function in msvcrt.dll is not compatible with C11 and therefore you get lot of errors.
Windows provides C11 standard functions in UCRT libraries. msvcrt.dll provides only subset of C89.
So you really should not compile your application with -nostdlib if your intention is to produce executable application and use standard C functions.
You can instruct new gcc to compile your C application as C89 with option -std=c89. This should instruct new gcc to behave like old gcc.
I'm new to GNU and GCC, sorry if my question sounds dumb.
We know that GCC stands for GNU Compiler Collection, so I think gcc is just a compiler (from a compiler collection).
But I also read that gcc is a compiler driver which contains Pre-processor (cpp), Compiler (cc1), Assembler (as) and Linker (ld).
So it looks that GCC is not a compiler, but why wiki says:
"GCC is a key component of the GNU toolchain and the standard compiler for most projects related to GNU and Linux"
and what does "1" means in cc1, why it is called cc1, not cc2, cc3 ...etc?
In most cases you (a little inaccurately) call gcc the compiler. A reason is that you can run the whole tool chain, at least for simple projects, with a single gcc command. Let's say you have this main.c
// main.c
#include <stdio.h>
int main(void)
{
printf("Hello, world!\n");
}
and compile it with
gcc main.c
Then everything you mentioned, cpp, cc1, as and ld will be involved in creating the executable a.out. Well, almost. cpp is old and newer versions of the compiler has the preprocessor integrated.
If you want to see the output of the preprocessor, use gcc -E main.c
As I mentioned, the preprocessor and the compiler is integrated nowadays, so you cannot really run cc1 without the preprocessor. But you can generate an assembly file with gcc -S main.c and this will produce main.s. You can assemble that to an object file with gcc -c main.s which will produce main.o and then you can link it with gcc main.o to produce your final a.out
https://renenyffenegger.ch/notes/development/languages/C-C-plus-plus/GCC/cc1/index (Emphasis mine)
cc1 is also referred to as the compiler proper.
cc1 preprocesses a c translation unit and compiles it into assembly code. The assembly code is converted into an object file with the assembler.
Earlier versions of cc1 used /usr/bin/cpp for the preprocessing stage.
https://renenyffenegger.ch/notes/Linux/fhs/usr/bin/cpp (Emphasis mine)
The preprocessor.
cpp is not bo be confused with c++.
The preprocessor is concerned with things like
macro expansion
removing comments
trigraph conversion
escaped newline splicing
processing of directives
Newer version of gcc don't invoke /usr/bin/cpp directly for preprocessing a translation unit. Rather, the preprocessing is performed by the compiler proper cc1.
I would almost consider this as a dup of this, but it's impossible to create cross site dupes. Relationship between cc1 and gcc?
Related: 'Compiler proper' command for C program
and what does "1" means in cc1, why it is called cc1, not cc2, cc3 ...etc?
Don't know. My first guess was that they just added a 1 to cc which was and is the standard compiler on Unix (excluding Linux) systems. On most Linux system, cc is just a link to gcc. But another good guess is that it stands for the first phase in compilation. Have not found a good source though.
I would like to know how to link a pgc++ compiled code (blabla.a) with a main code compiled with c++ or g++ GNU compiler.
For the moment linking with default gnu c++ linker gives errors like:
undefined reference to `__pgio_initu'
As the previous person already pointed out, PGI supports G++ name mangling when using the pgc++ command. Judging from this output, I'm guessing that you're linking with g++ rather than pgc++. I've had the most success when using pgc++ as the linker so that it finds the PGI libraries. If that's not an option, you can link an executable with pgc++ -dryrun to get the full link line and past the -L and -l options from there to get the same libraries.
Different C++ compilers use different name-mangling conventions
to generate the names that they expose to the linker, so the member function
name int A::foo(int) will be emitted to to the linker by compiler A as one string
of goobledegook, and by compiler B as quite a different string of goobledegook,
and the linker has no way of knowing they refer to the same function. Hence
you can't link object files produced by different C++ compilers unless they
employ the same name-mangling convention (and quite possibly not even then: name-mangling
is just one aspect of ABI compatibility.)
That being said, according to this document,
PGC++ supported name-mangling compatibility with g++ 3-and-half years ago, provided that PGI C++ compiler was invoked with precisely the command pgc++ or pgcpp --gnu. It may be that the library you are dealing with was not built in that specific way, or perhaps was built with an older PGI C++ compiler.
Anyhow, if g++ compiles the headers of your blabla.a and emits different
symbols from the ones in blabla.a, you can't link g++ code with blabla.a.
You'd need to rebuild blabla.a with g++, which perhaps is not an option.
I get the following error when dealing with C using Fedora:
[king#localhost ~]$ gcc -o1 tempdaa.c
tempdaa.c:3:17: fatal error: queue: No such file or directory
#include <queue>
^
compilation terminated.
Any ideas on where the problem is?
gcc is generally what you use to compile C code. If you want to compile C++ code, you'd tend to use g++.
Now it's true that gcc can compile C++ if it's clear you have a C++ program but I think, from memory, that's indicated by the extension rather than the content.
Since your extension is .c rather than something like .cpp or .cc or .cxx, it will definitely think it's C code and behave accordingly.
Hence the C++ header queue will not be available to you.
My suggestion is that you name your C++ source files "correctly", or force the language type explicitly:
gcc -x c++ -o1 tempdaa.c