There's a C++ code:
#include <stdio.h>
int main() {
int b = sizeof('a');
if(b==4) printf("I'm a C program!\n");
else printf("I'm a C++ program!\n");
}
Compile it like this:
gcc main.cpp -o main
It succeeds and gives:
I'm a C++ program!
Then add a line somewhere inside function main
int *p1 = new int [1000];
It fails with:
C:\Users\...\AppData\Local\Temp\cccJZ8kN.o:main1.cpp:(.text+0x1f): undefined reference to operator new[](unsigned long long)'
collect2.exe: error: ld returned 1 exit status
Then the following two commands successfully compile the code:
gcc main.cpp -o main -lstdc++
and
g++ main.cpp -o main
The compiler is minGW-win64 (http://mingw-w64.sourceforge.net/).
The questions are:
Which of the two last commands are better?
To my mind gcc correctly chooses the right compiler but then uses a wrong linker. Is it right?
May it be a problem in minGW-win64?
As I see (correct me if it's wrong) gcc was intended to be a main program that takes the input and decides what to do with it. So I'd better use gcc if it worked without -lstdc++. But if it's not possible I'll prefer using g++ instead as don't know what else gcc may miss.
Many thanks for your considerations
gcc is the GCC compiler-driver for C programs, g++ is the one for C++ programs.
Both will guess the language on the basis of the file-extension, unless overridden.
But if you use the wrong driver, the default-options will be wrong, like leaving out the C++ standard-library for C++ programs compiled with gcc when linking.
You can add just the library with -lstdc++, though using the proper driver is preferable, as plain gcc may be missing other, subtler options.
Related
I have a simple proof case file, which is called main.c
void bar(void);
void foo(void)
{
bar();
}
int main(void)
{
return 0;
}
As you can see there is no definition for bar()
My goal is to compile this on windows using cygwin's gcc.
I have figured out that I could use the following linker option:
--unresolved-symbols=ignore-all
This should tell the linker not to care about missing symbols. In the main.c example the missing symbol would not even be an issue, as foo is never called, therefore there should not be an undefined behavior when the program is executed.
I have 2 flavors of gcc, one for embedded ARM targets, and one from cygwin 64bit for windows.
The embedded ARM gcc is from here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm , version 4_9-2015q3.
The Cygwin gcc is taken from https://cygwin.com 's 64bit installer, version 7.3.0-1
I use these compile options with the compilers:
arm-none-eabi-g++.exe -Wl,--unresolved-symbols=ignore-all main.c
g++.exe -Wl,--unresolved-symbols=ignore-all main.c
The first compiles and links without errors, as for the second I get this error message:
/cygdrive/c/Users/user/AppData/Local/Temp/ccRF8tf5.o:main.c:(.text+0x9): undefined reference to `bar()'
/cygdrive/c/Users/user/AppData/Local/Temp/ccRF8tf5.o:main.c:(.text+0x9): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `bar()'
collect2: error: ld returned 1 exit status
Where clearly the undefined reference to `bar()' message should have been suppressed by the option -Wl,--unresolved-symbols=ignore-all
(The second error message does not appear, if I use gcc from the 32 bit cygwin installer.)
The --help command for the cygwin ld shows the --unresolved-symbols=ignore-all as a valid option.
I suppose the cygwin gcc has been compiled in a way, that this option does not work, even though it is not complaining that it can not validate this option.
If for example I use this command:
g++.exe -Wl,--unresolved-symbols=dummy main.c
I get this error message:
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: bad --unresolved-symbols option: dummy
Which for me tells, that --unresolved-symbols is in fact is an accepted command.
My questions would be:
Is there a way to see which commands are truly accepted by gcc
Is there some other way that could work using cygwin's gcc to compile this main.c example?
Compiling gcc for windows from sources with the proper option could maybe get --unresolved-symbols to work?
My motivation for this whole thing is that I want to unit test a single function from big files, that have multiple functions. Like in the following example:
#include "foobar.h"
int foo(void)
{
return 0;
}
void bar(void)
{
foobar();
}
The declaration of foobar() is in the foobar.h and the definition is in another file called foobar.c
If I wanted to run a unit test, which just links against the symbol foo() I would still get a linker error because of the missing symbol for foobar(). (linking against foobar.o would lead me to link to the complete chain of dependencies, which I want to avoid)
If this --unresolved-symbols option would work, then I would not need to mock or stub the foobar() function in my unit test.
I do understand that there are tools that can create automatically mocks, nevertheless I would like to get this to work.
Thanks for reading through.
I am making a parallel program for one of my courses. Now initially it was written in C and it all worked just fine. Then we changed it all to c++ and all of a sudden I get some error when I try to compile the program. I am using the package mcbsp (Multicore BSP) for the parallel part. Here is the program
#include <stdio.h>
#include <stdlib.h>
#include <mcbsp.h>
void sieve(){
return ;
}
main(int argc, int **arhv){
bsp_begin(5);
printf("%d\n",bsp_pid());
bsp_end();
return 0;
}
So I make a file aaa.c and aaa.cpp both with this content. Then when I type in the terminal
gcc aaa.c -MMD -g -I../bsp/include -L../bsp/lib -lmcbsp1.2.0 -lpthread
it compiles just fine and the program does as expected (print the id of the cores). However, when I type
g++ aaa.cpp -MMD -g -I../bsp/include -L../bsp/lib -lmcbsp1.2.0 -lpthread
it gives the following feedback
/tmp/ccH3uox9.o: In function `main':
/home/teun/Documents/C/BSP/Sieve/sieve/aaa.cpp:10: undefined reference to `bsp_begin(unsigned int)'
/home/teun/Documents/C/BSP/Sieve/sieve/aaa.cpp:11: undefined reference to `bsp_pid()'
/home/teun/Documents/C/BSP/Sieve/sieve/aaa.cpp:12: undefined reference to `bsp_end()'
collect2: error: ld returned 1 exit status
I have been stuck with this for about an hour now and it is really getting frustrating. I must admit that I have little experience in programming in c++ as I mostly use C. Does anyone know what is going wrong?
EDIT: The program I displayed is just a small working example that uses the BSP functionality.
The simple declaration int bsp_end(); is interpreted differently in C and C++. The reason is that in C++, you can overload functions, which requires that their parameters are included in the symbol name for the linker, see C++ name mangling for further info. Now, since the function is compiled with a C compiler but the declaration is given to a C++ compiler, the symbols don't match and you get linker errors.
As a solution, add extern "C" to the function declaration or maybe wrap the whole include:
extern "C" {
#include <mcbsp.h>
}
You need extern "C" around #include
extern " C" {
#include "c-header.h"
};
This is needed to stop the C++ name mangling
I should couple in linux one c++ code with old fortran code, where fortan is the main code. Im not expert in this area and I try to start with simple test, but still I cannot compile it. Maybe I'm stupid, but I cannot find a working example anywhere. I managed to compile fortran and c, when the linking can be done by ifort (need to use intel compiler later with the actual fortran code). But If I've understood right, with c++, the linking must be done by c++ compiler (g++).
So what do I do wrong here:
My FORTRAN test code "ftest.f":
PROGRAM MAIN
IMPLICIT NONE
INTEGER I
write(*,*) "hello fortran1"
CALL ctest()
write(*,*) "hello fortran2"
END PROGRAM
And C++ code "ctest.cpp"
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <string.h>
#include <iostream>
extern "C" void ctest_();
void ctest_(){
int i;
// std::cout << "hello c \n";
printf("hello c\n");
}
I try to compile with the following:
ifort -c ftest.f
g++ -c ctest.cpp
g++ -ldl -lm -limf -L -l -lifcore ctest.o ftest.o
And I get an error:
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
So what should I do to success with linking this program?
Your main (entry) is in Fortran part, so one way to solve it is to to use ifort linker instead of g++ (that would also link ifcore automatically)
ifort ctest.o ftest.o ... -lstdc++
So looks like I truested too much on one page telling me that I have to use c++ compiler for linking. Earlier just always something else was wrong when trying to link by ifort.
So using ifort with -lstdc++ is really enough with the current version of my test code. Earlier just something else was wrong.
Thank you very much once again, I wish you all the best for your own projects!
This question already has answers here:
How to resolve the linker error in C++ compiler
(3 answers)
Closed 9 years ago.
I'm using 64-bit CentOS version of Linux. I'm trying to create and use a static library (libUtility.a) in my C and C++ programs. I can compile the library with C, and produce the libUtility.a file with ar. Then I try to link it into my program. Everything works when I use the C compiler
cc myprog.c -o myprog -I/usr/local/include -L/LocationOfMyLib -lUtility
However, when I use the g++ compiler, I receive the errors.
g++ myprog.c -o myprog -I/usr/local/include -L/LocationOfMyLib -lUtility
myprog.c: In function 'int main(int, char**)':
/tmp/cckIN1Yk.o: In function `main':
myprog.c:(.text+0x41): undefined reference to `Utility_HiWorld(char*)'
collect2: ld returned 1 exit status
I have moderate experience in C and C++, but no experience creating my own
libraries. This library only has one subroutine named Utility_HiWorld(). And myprog.c only calls that one subroutine. What am I doing wrong in here?
NEW: Okay, I definitely didn't use 'extern "C"'. I didn't even know what that was. That solved it.
I would guess that you are failed to tell your C++ compiler that the external function is written in C.
Since you want to use the library from C and C++ you need to do something like this in your libraries header file.
#ifdef __cplusplus
extern "C" {
#endif
void Utility_HiWorld(char*);
#ifdef __cplusplus
}
#endif
__cplusplus is only defined for a C++ programs, so a C++ program will see extern "C" { ... } which is what it needs to tell it that Utility_HiWorld is a C function.
See here for more details.
Just a guess, post some code if you think the problem is something else.
I know there are many questions related to shared libraries on Linux but maybe because I'm tired of having a hard day trying to create a simple dynamic library on Linux (on Windows it would have taken less than 10 minutes) I can't find what happens in this case.
So, I am trying to create a library to be linked at build-time and used at run-time (not a static library, not a library to be embedded into the executable, in other words). For now it contains a simple function. These are my files:
1.
// gugulibrary.cpp
// This is where my function is doing its job
#include "gugulibrary.h"
namespace GuGu {
void SayHello() {
puts("Hello!");
}
}
2.
// gugulibrary.h
// This is where I declare my shared functions
#include <stdio.h>
namespace Gugu {
void SayHello();
}
3.
// guguapp.cpp
// This is the executable using the library
#include "gugulibrary.h"
int main() {
GuGu::SayHello();
return 0;
}
This is how I try to build my project (and I think this is what is wrong):
gcc -Wall -s -O2 -fPIC -c gugulibrary.cpp -o gugulibrary.o
ld -shared -o bin/libGugu.so gugulibrary.o
gcc -Wall -s -O2 guguapp.cpp -o bin/GuGu -ldl
export LD_LIBRARY_PATH=bin
This is saved as a .sh file which I click and execute in a terminal. The error I get when trying to link the library is this:
/tmp/ccG05CQD.o: In function `main':
guguapp.cpp:(.text.startup+0x7): undefined reference to `SayHello'
collect2: ld returned 1 exit status
And this is where I am lost. I want the library to sit in the same folder as the executable for now and maybe I need some symbols/definitions file or something, which I don't know how to create.
Thanks for your help!
In your C++ file, GuGu::SayHello is declared as a C++ symbol. In your header, you are wrapping it in an extern "C" block. This is actually undefined, as you aren't allowed to use C++ syntax (namespace) in that context. But my guess is that what the compiler is doing is ignoring the namespace and generating a C symbol name of "SayHello". Obviously such a function was never defined by your library. Take out the extern "C" bits, because your API as defined cannot be used from C anyway.
You are inconsistent with your GuGu, there are also Gugu's running around, this needs to be made consistent, then it works (At least on my computer are some Gugu's now)