I read somewhere that c++ object files must be linked only through g++ not gcc. Is it true? if yes, then how to link object files belong to c, c++ and asm?
If you use g++ to link, then it will automatically link with the C++ runtime library. If you link with gcc you have to link with the runtime manually.
That's the only difference.
The gcc and g++ programs are only special front-end wrapper programs, that invoke the correct preprocessor, compiler, assembler and linker for the files provided.
Yes, you have to use G++ to link C++ due to name mangling.
See the topic here https://en.wikipedia.org/wiki/Name_mangling
C++ names are C-abi compatible, you can link C++ object files to C code.
Related
I have ported a project to an arm cortex M7 chip, and am mucking around with makefiles for the first time, im using the gnu-gcc compiler collection.
Is it advisable to compile "c" code with the gcc driver and, compile the "c++" (app) code with the g++ driver, and then link. The c code is all low level (header files)register access addresses etc and contains no functions (yet) or attached source files.
Or can i compile all with the g++ compiler if the header files can be modified to compile with g++ if needed.
I have it set so gcc is compiling the c files, and g++ is compiling c++ and linking.
The only differences between gcc and g++ are that:
when the driver is used to invoke the linker, g++ causes libstdc++ to be linked as part of "stdlibs", while gcc will link only libc.
g++ will compile .c, .h and .i files as C++ unless the -x option is specified.
Both drivers will compile C or C++ depending on either the filename extension, or command-line switches. If you invoke the compiler-driver for compilation only and invoke the linker (ld) directly, using gcc or g++ -x, it makes no difference which you use.
Equally, if you invoke the gcc driver for C++ code and explicitly link stdlibc++ it also makes no difference - so long as your crt0.o is not C-only - a C++ runtime start-up must invoke global static constructors before main()) - this is likely to already be the case.
The definitive word from the documentation:
3.3 Compiling C++ Programs
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).
However, the use of gcc does not add the C++ library. g++ is a program
that calls GCC and automatically specifies linking against the C++
library. It treats ‘.c’, ‘.h’ and ‘.i’ files as C++ source files
instead of C source files unless -x is used. This program is also
useful when precompiling a C header file with a ‘.h’ extension for use
in C++ compilations. On many systems, g++ is also installed with the
name c++.
When you compile C++ programs, you may specify many of the same
command-line options that you use for compiling programs in any
language; or command-line options meaningful for C and related
languages; or options that are meaningful only for C++ programs. See
Options Controlling C Dialect, for explanations of options for
languages related to C. See Options Controlling C++ Dialect, for
explanations of options that are meaningful only for C++ programs.
If you want to use just one, I suggest you use gcc and separately invoke the linker or explicitly link -libstdc++. That way the compilation mode will be dependent on the filename extension. Using g++ -x to compile C code is just going to cause confusion.
Can I create a shared library from the C and C++ object files?. If possible where should I use it? (in C/C++ applications or both).
You can create shared library from .o file (Create from C or C++ file) and use it into C or C++ application.
There is here and here tutorials about shared library that show how compile shared library and how use it.
If you have any question about it, you are welcome.
Not all situation you can do that. If you have source code, you can compile them as:
gcc -fPIC exam.c -o exam.o
gcc -shared exam.o -o libexam.so
PIC means position-independent code. And if a object file is compiled with -fPIC, it can be used to create shared lib.
When compiling a c file that uses old style function definition like
int foo(a)
int a;
{
...
}
g++ will give and error: ‘a’ was not declared in this scope.
gcc can parse this.
Is there a way to let g++ recognize this?
This comes up as an issue to me because I'm compiling a mix of c and c++ files.
A related question is what's the standard practice
of building this type of mixed source? Running g++ on all files or only the cc files? The former is convenient but keeps getting me some trouble because of the inconsistencies between c and c++ specification(for example, char[4]="four";)
Is there a way to let g++ recognize this?
This syntax is not supported in C++.
Running g++ on all files or only the cc files?
See e.g. Compiling C++ programs from the GCC docs:
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).
However, the use of gcc does not add the C++ library. g++ is a program that calls GCC and treats .c, .h and .i files as C++ source files instead of C source files unless -x is used, and automatically specifies linking against the C++ library. This program is also useful when precompiling a C header file with a .h extension for use in C++ compilations.
So two possibilities:
Run gcc on C files, and g++ on C++ files.
Run gcc on all files.
In both cases you will need to link with g++ (or gcc -lstdc++).
Oli is correct: C++ doesn't support old-style function definitions.
Compile C with a C compiler (such as gcc).
Compile C++ with a C++ compiler (such as g++).
They're two different (though closely related) languages. You can use C++'s extern "C" feature to invoke C code from C++ and vice versa; see section 32 of the C++ FAQ Lite for more information.
If you are going to compile both C and C++, you are better off compiling always with gcc (it will choose the language based on the file extension) than g++ (will always compile as C++). You will need to change your linker options to include C++ standard library (and -lm if you use it) as those are automatically added by g++ but not gcc.
Alternatively, a better option is to call the g++ for C++ and gcc for C files. That should not be too hard to manage by configuring the build system.
Are there any differences in the linking process between gcc and g++?
I have a big C project and I just switched part of the code to C++. The code isn't using std C++ library yet, so -llibstdc++ isn't needed for now.
The main difference is that (assuming the files are detected as C++) g++ sets up the flags needed for linking with the C++ standard library. It may also set up exception handling. I wouldn't rely on the fact that just because your application doesn't use the standard library that it isn't needed when compiled as C++ (for example the default exception handler).
EDIT: As pointed out in comments you'll have trouble with any constructors (that do work) for static objects as well as not getting virtual function tables (so if you're using those features of C++ you still need to link that library).
EDIT2: Unless you're using C99 specific code in your C project I would actually just switch to compiling the whole thing as C++ as the first step in your migration process.
gcc and g++ are both just driver programs that don't do anything other than calling other programs, so you can use the -v option to see exactly what they do -- what other programs they invoke with what args. So you can see exactly what the difference is between linking with gcc and g++ for the specific version and architecture of gcc that you happen to have installed. You can't rely on that staying the same if you want portability, however.
Depending on what you are doing, you might also be interested in the -### argument
I think that the g++ linker will look for the CPP mangled function names, and it is different from the C ones. I'm not sure gcc can cope with that. (Provided you can explicitly use the C version rather than the C++ one).
Edit:
It should work if you have
extern "C" {
<declarations of stuff that uses C linkage>
}
in your code and the object file has been compiled with g++ -c. But I won't bet on this.
I have a static library that has been compiled with gcc 3.4.3 .I would like to use this in code that will now be compiled with gcc-4.
I've read vaguely that gcc-3 and gcc-4 binaries are not compatible and that the library will need to be recompiled , but just want confirmation on this.
Isn't there anyway a gcc-3 library can be used with gcc-4 ?
Getting someone else in the organization, or at a vendor, to update their library to gcc 4 is not always an option, especially if they've abandoned it.
If C++: assuming that are able to link, at runtime you can blow up in C++ standard library template code that uses streams, as symbols generated by g++ 4 are resolved against definitions generated by g++ 3.
You might see this warning when linking:
/usr/bin/ld: warning: libstdc++.so.5, needed by (legacy static lib), may conflict with libstdc++.so.6
Here's an example you can get into: base class destructor ~basic_stringbuf() (actually a template) can be defined in your module compiled under g++ 3, which mistakenly gets called by the destructor ~basic_ostringstream() in libstdc++so.6, which is invoked by the g++ 4 compiled module. Ka-Boom.
I tried compat-libstdc++-33 but had no luck with that.
That said, I still link 32-bit gcc 3 era C libraries into my gcc 4.1.2 C++ programs.