I am trying to compile a valid Fortran 77 file using the gfortran compiler. I use the following command to compile the Fortran:
gfortran -c main.f -o main-fortran.o -llapack -lblas
I also need to link this with a C++ program, which is compiled, like so:
g++ -c main.cpp -o main-cpp.o
Both of these files compile without any errors or warnings.
However, I cannot link them together into an executable. Here is the command I am using:
g++ main-cpp.o main-fortran.o -o run.exe -lgfortran -llapack -lblas
The linker then gives this error:
main-fortran.o: In function `main':
main.f:(.text+0x2e18): multiple definition of `main'
main-cpp.o:main.cpp:(.text+0x8e9): first defined here
collect2: ld returned 1 exit status
You can find the source files here: C++ and Fortran 77.
Any idea what I can do to overcome this?
You have two main programs: one in C++ and one in Fortran. Delete the Fortran one either by
Option 1:
The first bit of your Fortran program should be a BLOCK DATA segment. Just add
BLOCK DATA INFO
At the start.
Option 2:
Delete everything up to the first END.
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'
I'm busy trying to compile and link a c++ program using the following make file
driver.so:driver.cpp
g++ -c driver.cpp -o driver.so
g++ -L/tokenlib/libtokenlib.so driver.so -o linked
but I'm getting the error
g++ -c driver.cpp -o driver.so
g++ -L/tokenlib/libtokenlib.so driver.so -o linked
driver.so: In function `main':
driver.cpp:(.text+0x9): undefined reference to `tokenlib::acquire_token()'
collect2: error: ld returned 1 exit status
make: *** [driver.so] Error 1
and my file hierarchy is
/root
makefile
driver.cpp
/tokenlib
libtokenlib.so
I've been told that adding -Wl,-rpath=./tokenlib to my g++ arguements would solve the problem so I tried like this
driver.so:driver.cpp
g++ -c driver.cpp -o driver.so -Wl,-rpath=./tokenlib
g++ -L/tokenlib/libtokenlib.so driver.so -o linked -Wl,-rpath=./tokenlib
but it still isn't working.
I'm a complete novice and any help would be appreciated.
The linker usually refers to .a (stub) libraries, not to .so files!
-L options specify the paths, the lnker should take in account.
The -l<mystuff> option tries to resolve a library named libmystuff.a from any of the given path's of the -L options, or compiler intrinsic library search paths.
I have a requirement of creating a C++ program which exposes certain functions through HTTP. For that reason I was trying to use libmicrohttpd for the same. Now this library is written in C. However I am kind of new to C++ and am trying to compile this C and C++ code given here. (Which can be git cloned from here)
Now I need help in understanding how g++ may be used to compile a program which is not written completely in C++. And/or how to compile the above linked code.
PS: Working in linux
And finally if someone can point to an easier alternative than libmicrohttpd - I am all ears.
Edit to Edit:
Finally got it working. Compiled the individual cpp files with gcc and then linked everything using g++. I have no clue how this came to work, maybe some one can reply below.
I have made the following script to compile and link:
LOC="path/to/directory"
gcc -c httphandler.cpp -o httphandler.o -I $LOC
gcc -c strutil.cpp -o strutil.o -I $LOC
gcc -c api.cpp -o api.o -I $LOC
gcc -c executor.cpp -o executor.o -I $LOC
g++ -o out httphandler.o strutil.o api.o executor.o -lmicrohttpd -lboost_regex
But in the final step I am getting the following error:
/usr/bin/ld: strutil.o: undefined reference to symbol '__cxa_free_exception##CXXABI_1.3'
/usr/bin/ld: note: '__cxa_free_exception##CXXABI_1.3' is defined in DSO /usr/lib/x86_64-linux-gnu/libstdc++.so.6 so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: could not read symbols: Invalid operation
What gives?
For starters, don't compile the C code with g++, use gcc instead. Then just include the header file and use the functions normally. When linking don't forget to link with the object file(s) generated from compiling the libmicrohttpd source file(s).
I came across this while trying to get an answer. But it seems like the poster had multiple files and they were not getting linked, and hence the error.
But, why do I get this error when using a single file?
g++ myClass.cpp
/usr/lib/gcc/i686-redhat-linux/4.6.3/../../../crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
And why is main necessary here at compile time (from where does it find a mention of main in my code) ? main is the starting point of code execution, but why does the compiler assume i need a main here. I can have it defined in some other file and use gcc -o to make an executable?
Or maybe I am missing something else in the code which causes the error?
#include<iostream>
class myClass
{
public:
myClass()
{
std::cout<<"Constructor";
}
~myClass()
{
std::cout<<"Destructor";
}
};
main is not necessary to compile a source file. It is necessary to link a program into an executable [1], because the program has to start somewhere.
You need to tell the compiler that "this is not the whole of my program, just compile, but don't link", using the '-c' option, so
g++ -c myClass.cpp
which will produce a myClass.o file that you can then use later, e.g.
g++ -o myprog myClass.o myOtherClass.o something_that_has_main.o -lsomelib
(Obviously, substitute names with whatever you have in your project)
[1] Assuming you use the regular linker scrips that come with the compiler. There are "ways around that too", but I think that's beyond this answer.
You are trying to compile an executable, so a main function is expected. You should compile an object file by using the -c flag:
g++ -c myClass.cpp
While you are at it, I suggest adding warning flags -Wall -Wextra at the very least.
You are building your source as an application. Add -c option to produce only object file:
g++ -c myClass.cpp
Compile only?! use -c option
g++ -c file.cpp
otherwise the project needs a main.
You need to use the -c flag to compile and only tell the compiler to generate an object file. You're telling the compiler to make an executable.
I'm writing a small C program that uses librt. I'm quite surprised that the program won't compile if I place the link flag at the start instead of at the end:
At the moment, to compile the program I do:
gcc -o prog prog.c -lrt -std=gnu99
If I were to do the following, it will fail to find the functions in librt:
gcc -std=gnu99 -lrt -o prog prog.c
Yet, this works with other libraries. I found the issue when attempting to use a simple Makefile. make actually compiled prog.c without liking first (using -c flag) and then did the linking.
This is the Makefile:
CC = gcc
CFLAGS = -std=gnu99
LIBS= -lrt
LDFLAGS := -lrt
prog: prog.o
$(CC) -o prog prog.c -lrt -std=gnu99
The output I would get when typing make would be:
gcc -std=gnu99 -c -o prog.o prog.c
gcc -lrt prog.o -o prog
prog.o: In function `main':
prog.c:(.text+0xe6): undefined reference to `clock_gettime'
prog.c:(.text+0x2fc): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make: *** [buff] Error 1
I have now crafted a Makefile that puts the linking at the end of the gcc line, however I'm puzzled why it doesn't work if the linking flag is at the start.
I would appreciate if anybody can explain this to me. Thanks.
As the linker processes each module (be it a library or a object file), it attempts to resolve each undefined symbol while potentially adding to its list of undefined symbols. When it gets to the end of the list of modules, it either has resolved all undefined symbols and is successful or it reports undefined symbols.
In your case, when it processed librt, it had no undefined symbols. Processing proc resulted in clock_gettime being an undefined symbol. gcc will not go back and look in librt for the undefined symbols.
For that reason, you should always have your code first, followed by your libraries, followed by platform provided libraries.
Hope this helps.
From the ld (the GNU linker) documentation (http://sourceware.org/binutils/docs/ld/Options.html#Options):
The linker will search an archive only once, at the location where it is specified on the command line. If the archive defines a symbol which was undefined in some object which appeared before the archive on the command line, the linker will include the appropriate file(s) from the archive. However, an undefined symbol in an object appearing later on the command line will not cause the linker to search the archive again.
So if you specify the library too early, the linker will scan it, but not find anything of interest. Then the linker moves on to the object file produced by the compiler and finds references that need to be resolved, but it has already scanned the library and won't bother looking there again.