I am having trouble compiling a program I have written. I have two different files with the same includes but only one generates the following error when compiled with g++
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crt1.o: In function `_start':
/build/buildd/eglibc-2.10.1/csu/../sysdeps/x86_64/elf/start.S:109: undefined reference to `main'
collect2: ld returned 1 exit status
The files I am including in my header are as follows:
#include <google/sparse_hash_map>
using google::sparse_hash_map;
#include <ext/hash_map>
#include <math.h>
#include <iostream>
#include <queue>
#include <vector>
#include <stack>
using std::priority_queue;
using std::stack;
using std::vector;
using __gnu_cxx::hash_map;
using __gnu_cxx::hash;
using namespace std;
Searching the internet for those two lines hasn't resulted in anything to help me. I would be very grateful for any advice. Thank you
To build two separate programs you need both source files to define main() function.
To build a single program out of two source files - first compile each file with -c options (compile only) - you will get two .o files, then link these files together. Something like this:
$ g++ -Wall -pedantic -ggdb -O -c -o module0.o module0.cpp
$ g++ -Wall -pedantic -ggdb -O -c -o module1.o module1.cpp
$ g++ -Wall -pedantic -ggdb -O -o prog module0.o module1.o
to build binary prog from two source files.
If you need to link with some library, you'll have to point compiler to it's headers with -I and to objects with -L flags, then tell the linker to actually reference the library with -l.
Hope this helps.
You need a main function and you don't have one. If you do have a main function, show more code please.
It looks like main is not defined. Do you have one defined for your second program? Can you post more details about the source body that fails to link?
Related
I am a very new to programming and have a very basic question that may be answered in other threads however I think they are far too advanced for me to understand how. I have actually found many answers so far on this site but this is the first problem that forced me to create an account and ask.
Anyway i am running a very basic example program on linux mint 18.3. Now I have seen this exact code work on a machine with windows 8 I believe so I was wondering if that could be the problem. I have created a class and when i plug in my object then build and run I get:
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o||In function _start':|
(.text+0x20)||undefined reference tomain'|
This is the entire code:
#include <iostream>
#include "Gladius.h"
using namespace std;
int main()
{
Gladius io;
return 0;
}
Thats it very basic. here is the .h
#ifndef GLADIUS_H
#define GLADIUS_H
class Gladius
{
public:
Gladius();
};
#endif // GLADIUS_H
and the .cpp for the class.
#include "Gladius.h"
#include <iostream>
using namespace std;
Gladius::Gladius()
{
cout << "The Gladius is a short sword" << endl;
}
I know this seems extremely simple but I am just learning to code and i have been looking all over for an explanation why this isn't working yet I see it work on another pc exactly as is. Anyway any explanation would be greatly appreciated.
Here is what i found in command line If this answers your questions about what was in the cmd.
g++ -Wall -fexceptions -g -std=c++11 -Wall -I -c /home/gator/Documents/Spartan1/Gladius.cpp -o obj/Debug/Gladius.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o: In function _start':
(.text+0x20): undefined reference tomain'
collect2: error: ld returned 1 exit status
Know the compiler options(gcc/g++ compiler):
-c : Compile and assemble, but do not link
-o file : Place the output into file
So when you run
g++ filename.cpp -o executable_name
, you generate an application which can be executed.
The problem is you are compiling, assembling as well as linking when you are trying to compile "Gladius.cpp" and compiler is trying to search for main() definition.
So in your case, the compilation steps would be:
First compile "Gladius.cpp" and generate object file "Gladius.o":
g++ -Wall -fexceptions -g -std=c++11 -c Gladius.cpp
Next compile "main.cpp" and generate object file "main.o":
g++ -Wall -fexceptions -g -std=c++11 -c main.cpp
Generate executable by linking "main.o" and "Gladius.o"
g++ -Wall -fexceptions -g -std=c++11 -o main main.o Gladius.o
Now you can run "main":
./main
Your compiler's command line contains -I -c sequence.
This -I option "swallows" your -c option. -I requires an additional argument, which is an include directory name. You failed to supply that argument, which is why -I assumes that -c that follows it is the directory name. So that -I consumes that -c.
The compiler never sees that -c. Without -c it assumes that you want to compile and link your program. Since Gladius.cpp does not have main in it, you get the error at linking stage.
Here 's a simple demo of the same problem: http://coliru.stacked-crooked.com/a/8a37cd3e90a443e2
You need to figure out why you have an orphaned -I in your command line.
If you are compiling this code using a command line like:
g++ -Wall -Wextra -Werror -O gladius.cpp -o output.exe
then make sure that you include all the .cpp files (not .h files) that contain code that your program needs.
g++ -Wall -Wextra -Werror -O gladius.cpp main.cpp -o output.exe
I explain this to beginners all the time as each .cpp being a bag of Lego's in a kit. You need all the bags that came with the box in order to build the kit. If you omitted main.cpp (or the file that contains main) then you will get the linker error that you are currently getting.
What command are you using to compile, link, and then execute? It should look something like
$ g++ main.cpp gladius.cpp -odemo
$ ./demo
check your command line for linking step.. You may forgot file with main as input, or you had forgot output file name after -o (and masked main.o in result)
I had this very kind of problem myself, and though it may not be the conventional, "proper" solution, I simply renamed the ".c" file to ".cpp", and it all worked.
After all, I was compiling both c and c++ together with a c++ compiler (recommended by the library), and the c code already had the proper c++ #extern flags (see here for more on that).
Also related:
C++ Error: undefined reference to `main'
Including C Code in C++
Why do you need an explicit `-lm` compiler option
Compilation on Linux - In function '_start': (.text+0x20): undefined reference to 'main'
So, I was following a simple C++ with SDL tutorial for linux but i encounter some errors on my way.
First of all I'm using Geany and i downloaded the corresponding SDL2 libs, here is the thing:
in my project folder there is a main.cxx file, which i open with geany as i mentioned before:
I included this libraries:
#include <iostream>
#include <SDL2/SDL.h>
#include <SDL2/SDL_image.h>
#include <SDL2/SDL_mixer.h>
First i encountered a pelculiar error, compilation performs sucessfully but when it comes to build i got this error:
main.cxx: undefined reference to `SDL_Init'
After searching a bit i found out that i had to add the tag -lSDL to my geany build options so they would end up being somethinf like this:
Compile:
g++ -Wall -c -lSDL "%f"
Build:
g++ -Wall -o -lSDL "%e" "%f"
But there is a problem, now when I execute the build command i get a:
G ++: error: main: There is no such file or directory
Why am i getting this error, am I including a wrong library or g++ has problems with .cxx files?
I already tried converting between .cxx and .cpp.
Thanks in advance.
g++ -Wall -c -lSDL2 "%f"
There is absolutely no need to specify libraries during compilation phase. Remove -lSDL.
g++ -Wall -o -lSDL2 "%e" "%f"
It invokes compiler, implies linking (no -c or other operation-specific flags), and sets output file name to -lSDL2. That is, linker will output resulting binary in a file named -lSDL2 in current working directory. Then, when it comes what files to link, it goes main, which supposed to be -o main, but since you've broken flags order it is now just ordinary file name that linker will try to link into resulting binary. It so happens that this file doesn't exist.
Long story short, make correct linking line - g++ -o "%e" %f -lSDL2 (libraries comes last, library order is also important).
As you see, there are multiple definitions of testfn symbol while linking, but the linker takes the first occurence (in linking order) and ignores the other occurances in other libraries.
This probably is the way how the linker works.
But Is there any way to enforce linker to flag error on seeing multiple symbols in different linked libraries ? Or any other options to catch such duplicate definitions ?
Content of test1.h:
#ifndef TEST1
#define TEST1
void testfn();
#endif
Content of test1.cpp
#include "test1.h"
#include <iostream>
using namespace std;
void testfn()
{
cout << "file1" << endl;
}
Content of test.h:
#ifndef TEST
#define TEST
void testfn();
#endif
Content of test.cpp:
#include "test.h"
#include <iostream>
using namespace std;
void testfn()
{
cout << "file" << endl;
}
Content of main.cpp:
#include "test.h"
#include "test1.h"
int main()
{
testfn();
return 0;
}
Created a shared libraries.
g++ -fPIC -shared libtest1.so test1.cpp
g++ -fPIC -shared libtest.so test.cpp
Created executable with library order#1
g++ -o main main.cpp -ltest -ltest1
Created executable with library order#2
g++ -o main1 main.cpp -ltest1 -ltest
Ouput of main
./main
file
Ouput of main1
./main1
file1
First of all, it is honoring the ODR, by only taking one of the methods out of the library. And that's just the way shared libraries work.
If you want to see the compiler complain about this, link them all together, without the library step.
g++ -o main1 main.cpp test1.cpp test.cpp
So your question becomes, "How do I tell if I have two libraries which both contain a indentifier with the same name?" Keep in mind that this is often not a problem and sometimes done intentionally. I'd suggest running the library tool (I'm not familiar with the g++ toolset) to get listing of the libraries, and run DIFF of them.
I don't see a way to get GNU ld to complain about multiple symbol definitions across shared libraries. However, if normal static library archives are involved, you might be able to use the --whole-archive/--no-whole-archive set of options to get what you want:
For example, after building libtest.a and libtest1.a instead of the shared library versions, I get no errors with the following link commands:
$ g++ -o main main.cpp -ltest1 -ltest -L.
$ ./main
file1
$ g++ -o main main.cpp -ltest -ltest1 -L.
$ ./main
file
But do get errors for the following:
$ g++ -o main main.cpp -Wl,--whole-archive -ltest1 -ltest -Wl,--no-whole-archive -L.
./libtest.a(test.o): In function `testfn()':
test.cpp:(.text+0x0): multiple definition of `testfn()'
./libtest1.a(test1.o):test1.cpp:(.text+0x0): first defined here
collect2: ld returned 1 exit status
I'm not sure you would want to use --whole-archive for release builds - maybe only as a sanity check for possibly name conflicts (I think that using --whole-archive normally will increase the size of your binary for no good reason).
Also, as mentioned before, this seems to have no effect on shared libraries.
Yes this question has been asked before ... I've tried everything mentioned in the previous answers. My setup is really straightforward so this shouldn't be so hard.
I just want to program against mysql using C++. My source code is taken verbatem from the 'hello world' type example here:
http://dev.mysql.com/doc/refman/5.1/en/connector-cpp-examples-complete-example-1.html
I am on Ubuntu 12.10. I am trying:
g++ -Wall -o firsttry_prog -I/usr/include/mysqlcppconn -I/usr/local/boost_1_53_0 -L/usr/lib/x86_64-linux-gnu -l:libmysqlclient_r.so.18 -L/usr/lib/mysqlcppconn -lmysqlcppconn firsttry.cpp
It compiles (if I use -c option) but won't build, giving me the infamous:
/tmp/ccn768hj.o: In function `main':
firsttry.cpp:(.text+0x3a): undefined reference to `get_driver_instance'
A few details:
'firsttry.cpp' is just what I named the source code file, again taken verbatem from the official example
As you can see I AM linking in the mysqlclient library and the mysqlcppconn library. Many times when this question has been asked previously, the answer was to link those.
Some other historical answers suggest the sample source code is wrong and that the function in question needs to be in the sql::mysql namespace etc. I am pretty sure the source code is fine. Again, it compiles, and changing the namespaces in the source code just seems to make it worse.
Thank you in advance for any help you can provide.
So I have now had this problem for a week now and I became very frustrated with it as well. I just now was able to finally build a program that does nothing except login to mysql and I literally squealed with joy. Here is what I have and I hope it helps.
I first compiled the c++ connector library from source but after a while I thought maybe I did something wrong so I then just used apt to get it with:
sudo apt-get install libmysqlcppconn-dev
And here is my simple tester source file "tester.cpp"
#include <stdlib.h>
#include <iostream>
#include <mysql_connection.h>
#include <driver.h>
#include <exception.h>
#include <resultset.h>
#include <statement.h>
using namespace sql;
int main(void){
sql::Driver *driver;
sql::Connection *con;
driver = get_driver_instance();
con = driver->connect("tcp://127.0.0.1:3306","root","YOURPASSWORD");
return 0;
}
And finally g++ compile command:
g++ -Wall -I/usr/include/cppconn -o testapp tester.cpp -L/usr/lib -lmysqlcppconn
This worked for me and I hope it helps you solve your problem!
For me simply swapping the order of the last two arguments fixed this problem. I don't know why but the linker is able to find the function get_driver_instance if I specify the -lmysqlcppconn option at the end after the source file.
g++ -Wall -o firsttry_prog -I/usr/include/mysqlcppconn -L/usr/lib/mysqlcppconn firsttry.cpp -lmysqlcppconn
Also note that I took out the following options as I think they are redundant
-I/usr/local/boost_1_53_0 -L/usr/lib/x86_64-linux-gnu -l:libmysqlclient_r.so.18
In case you are as forgetful as me and didn't link the library in CMakeLists.txt:
target_link_libraries(<target> mysqlcppconn)
If all the paths are included throw param -I. You would see whether there is a problem if you compile like this:
g++ -g -o0 -I/usr/local/include -I/usr/local/boost/include -c main.cpp -o main.o
g++ -g -o0 -L/usr/local/lib -L/usr/local/mysql/lib -lmysqlcppconn main.o -o test
the problem will appear:
main.o: In function `main':
/home/huangxw/workspace/public/soal/test/main.cpp:165: undefined reference to `get_driver_instance'
collect2: ld returned 1 exit status
Now you must adjust the order of -lmysqlcppconn and main.o:
g++ -g -o0 -I/usr/local/include -I/usr/local/boost/include -c main.cpp -o main.o
g++ -g -o0 -L/usr/local/lib -L/usr/local/mysql/lib main.o -o test -lmysqlcppconn
That is all!!
The reason is simple. You can find out using the web or ask me to elaborate.
I'm currently trying to compile an existing project which is a mix of cpp and c.
My makefile is as follows;
execute: mgnsvd.o multifit.o cit.o main.o
g++ -Wall -g multifit.o cit.o main.o mgnsvd.o -lgsl -lgslcblas -o execute
main.o: main.cpp cit.cpp
g++ -Wall -g -c main.cpp
cit.o: cit.cpp mgnsvd.c multifit.h
g++ -Wall -g -c cit.cpp
multifit.o: multifit.c mgnsvd.c multifit.h
g++ -Wall -g -c multifit.c
mgnsvd.o: mgnsvd.c
g++ -Wall -g -c mgnsvd.c
And my main is a rather plain
// global libraries
#include <iostream>
// local files
#include "cit.cpp"
// using directives
using std::endl;
using std::cout;
// main
int main(){
cout << "Hello, world" << endl;
return 0;
}
If is comment out #include "cit.cpp" it compiles fine. However, if i include it the following error happens;
ld: duplicate symbol _first_function_in_cit in main.o and cit.o for architecture x86_64
_first_function is always the first function, and is not defined or even declared/used anywhere else. A grep of the object files confirms the function seems to be incorporated into main.o, but why? I've not worked on a C++/C project before, so maybe I'm making some canonical error? I'm also in OSX, if that makes a difference.
For the record, there are no classes - the .h file contains a few structs and some macros.
cit.cpp is being compiled by itself, and is also included in main.cpp so you're getting two copies of all the code in it.
There is no need for
#include "cit.cpp"
cit.cpp is compiled as a separate unit and later linked.
With the above include you get the code twice with results in duplicate symbols
YOu are compiling cit.cpp to yield cit.o, and you are compiling it again with that #include "cit.cpp" attrocity in your main.cpp. So of course you are getting duplicate symbols.