I need to upload a .cpp file for a course application. The code works, i tried their test inputs, but when i upload my file it throws this error
</usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o: In function _start': (.text+0x20): undefined reference to main'
collect2: error: ld returned 1 exit status>
On the website it has a list of compilation commands that I assume have to somehow put into my code so the website can process my code?
Maybe that isnt even it, this is my first time dealing with this sort of thing, so any help is appreciated.
Tried just putting it into the code outside of main, didnt work.
Related
Hi I've never written a makefile before, but I tried my hand at it with my fortran90 final project and the makefile seems to have delete my main program. here's my makefile
# Sample makefile for several modules
#
FC = gfortran
final.x: subs.o func.o maina.o
gfortran -o final.x subs.o func.o maina.o
subs.o: subs.f90
gfortran -c subs.f90
func.o: func.f90
gfortran -c func.f90
maina.o: maina.f90
gfortran -c maina.f90
after running this, my maina.f90 was deleted and the I did not have a copy. this was what it showed when it was running. (The first output is when I ran it and found an error in subs, and after fixing these errors, I got the second output)
$ make
gfortran -o final.x subs.o func.o maina.o
subs.o: In function `__subs_MOD_gauss':
subs.f90:(.text+0x350): undefined reference to `f_'
subs.f90:(.text+0x366): undefined reference to `f_'
subs.o: In function `__subs_MOD_simp':
subs.f90:(.text+0x434): undefined reference to `f_'
subs.f90:(.text+0x4a2): undefined reference to `f_'
subs.f90:(.text+0x51b): undefined reference to `f_'
subs.o:subs.f90:(.text+0x571): more undefined references to `f_' follow
collect2: ld returned 1 exit status
make: *** [final.x] Error 1
$ make
gfortran -c subs.f90
gfortran -o final.x subs.o func.o maina.o
does anyone know why this file deleted my maina.f90, or (though it's probably unlikely) how to get my work back?
EDIT- I should add that I do not have admin or sudo privileges on this computer
Using the Makefile provided by the Pi GPIO library, I made the libpigpio.so shard object using:
# from line 119 in make file
make libpigpio.so
The shared object is created fine. The Makefile first created the pigpio.o object, then the command.o object, and links them together as a shared object. So far so good!
I wrote a very small main function that calls the gpioInitialise and gpioGetPWMfrequency.
It doesn't really matter which functions, what's important is they are defined in pigpio.h and written in pigpio.c.
Meaning the shared object should have them.
The compile command for my code is:
gcc -Wall -pthread -fpic -L. -lpigpio -o drive drive.c
Still I get the undefined reference error to both those functions.
It makes no sense! If it didn't find the shared object, it would reject the command. I also tried it -l:libpigpio.so and still the same problem.
I am compiling directly on the Rpi A+ (not using a cross compiler). So it should work!
What am I missing here?
It is a link order question. Please try the flowing command.
gcc drive.c -Wall -pthread -fpic -o drive -L. -lpigpio
you can read Why does the order in which libraries are linked sometimes cause errors in GCC? for more details.
I have need to compile and statically link a Chicken program. I expect to use many extensions, most notably http-client.
I can compile the source with the following command:
csc -compile-syntax -static linux-setup.scm
or
csc -R http-client -compile-syntax -static linux-setup.scm
But when I run it, I get the following error:
Error: (require) cannot load extension: http-client
Call history:
##sys#require <--
I have also tried (declare (uses http-client)) in the source, with no success:
linux-setup.o: In function `f_369':
/mnt/data/Documents/Programming/chicken-scheme/linux-setup/linux-setup.c:219:
undefined reference to `C_http_2dclient_toplevel'
collect2: error: ld returned 1 exit status
Error: shell command terminated with non-zero exit status 256: 'gcc' 'linux-setup.o'
-o 'linux-setup' -L"/usr/lib" -Wl,-R"/usr/lib" -static '/usr/lib/libchicken.a' -lm -ldl
Static linking is something I need. This is not an XY problem. I need my executables to run on a freshly-installed Linux system with no dependancies. This is the primary reason I switched from Common Lisp to Scheme in the first place.
What am I doing wrong, please?
Assuming your program is in a-program.scm file:
csc -deploy a-program.scm
cd a-program/
chicken-install -deploy -p $PWD http-client
...et voilà!
edit: turns out that the proper answer to the problem posted is solved in this document: http://www.foldling.org/scheme.html#compiling-statically-linked-chicken-scheme-programs-with-extensions
I try to write a Makefile that takes several static libraries that have been created before and link the to an executable. Although one libary has a main-routine.
I get the error:
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
make: *** [dockSIM_gcc_release] Error 1
I tried it with just linking the library that has the main routine but the error stays the same and comes directly after invoking make.
The Makefile:
SHELL = /bin/sh
RM=/bin/rm -f
CXX=g++
PROGNAME=dockSIM_gcc_release
DEFINES=-DDOCKSIM_VERBOSE=FALSE -DNDEBUG -DPRINT_LOG_MSG=0 -DPRINT_DEBUG_MSG=0
LDFLAGS = -fopenmp -g -O3 -std=c++11 -mavx -mstackrealign -fstrict-aliasing
LIBS= -lnagc_mkl -lm -L../externalCode -lpardiso500-GNU481-X86-64 -lacml
FILENAMES = commandInterpreter_lib.a
OBJNAMES =
all: $(PROGNAME)
$(PROGNAME): $(FILENAMES)
$(CXX) $(LDFLAGS) $(DEFINES) -o $(PROGNAME) $(FILENAMES)
clean:
$(RM) *.mo *.ho *.o $(PROGNAME) core *~
test:
echo $(FILENAMES)
showlibs:
echo $(LIBS)
The flags are compatible with those that were used to compile the code.
g++ 4.9.3 is used.
Signature of the main-Routine:
int main(int argc, char* argv[])
Thanks for help and kind regards.
I can only guess what's wrong.
There is more to linking a static library than just a convenient bundle of object files to reduce command line length. In addition to that, the linker only links in object files which it thinks are needed. An object file is needed if there's some undefined symbol that the linker is looking for, that is contained in that object. If there's no symbol that the linker needs in the object, then the linker ignores the object and doesn't link it.
The normal way to build a program is to have the main program listed as object files on the command line: the linker always links every object file. This gives the linker a set of symbols which are defined (by the object files) and undefined (things the object files use but that aren't defined by them). Then the linker will go through the libraries on the link line and add in object files that resolve undefined symbols. These object files in turn may have other undefined symbols that the linker will need to resolve later, etc.
All I can guess is that by not having any object files on your link line, the linker doesn't see the object file in the library containing main as needed and so it doesn't link it.
I don't know why building with debug vs. non-debug makes a difference.
I didn't understand your comment about why you need to do things this way: even if the person who knew about this left, someone will need to learn about it to maintain the software.
In any event you have a few options.
One simple one is to use the "ar" program to extract out the object file containing main and link it directly: in addition to adding objects to libraries ar can extract them. Then you can link that object directly. See the man page for ar.
Another would be to look at the documentation for your compiler and linker and find flags that will force it to include the entire library, not just the unresolved symbols in the library. For the GCC/binutils linker, for example, you can pass -Wl,--whole-archive before the libraries you want to be fully included on the command line, then -Wl,--no-whole-archive after them to turn off that feature.
This is the first time I am writing a makefile. This doesn't work (for example, if I modify ClientSocket.cc it just says "uptodate". Also throws up lots of dependency errors if I run make myprog). Can you please tell what is wrong in this?
Thank you
myprog: myprog.o Client.o ClientSocket.o Socket.o
g++ -Wall -g Socket.o ClientSocket.o Client.o myprog.o -o myprog
myprog.o: myprog.cc
g++ -Wall -g -c myprog.cc
Client.o: Client.cc Client.h
g++ -Wall -g -c Client.cc
ClientSocket.o: ClientSocket.cc ClientSocket.h
g++ -Wall -g -c ClientSocket.cc
Socket.o: Socket.cc Socket.h
g++ -Wall -g -c Socket.cc
Errors when running make myprog:
cc mprog.o -o myprog
myprog.o: In function `std::__verify_grouping(char const*, unsigned int, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
myprog.cc:(.text+0xe): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::size() const'
There are many others. Like:
myprog.cc:(.text+0x1a4): undefined reference to `std::cout'
myprog.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
Make sure you are using tabs to indent the command lines (it's impossible to tell whether you are or not from the post, since they would probably be converted to spaces).
EDIT:
From the cc line and the error messages, it looks like make is using its implicit rule for linking, completely ignoring the one you provided (the first one). I can't see anything in the makefile that would cause this. A few more things to check:
Try running other rules by typing, e.g., make Client.o and seeing if they work.
Check that all the files are in your current directory, and that the makefile is named Makefile
Again, I'm sure that it's just the formatting in the post, but your first rule is indented one more space than the other ones. You said you checked it, and I trust you, but I really can't see anything else wrong here.
I know these suggestions are like tech support asking you whether your computer is plugged in, but everything really looks fine to me. I even copied it, fixed the whitespace, and ran it on my machine. Everything seemed to work.
Did you name your file "Makefile" with a capital M?
You could also try running make -d for some debug information.
It doesn't look like a makefile problem (because the compiler is being invoked). It looks like a C++ source code problem.
Specifically, it looks like you are missing a #include in myprog.cc of the header that defines std::basic_string.
Have you tried executing the compiler commands directly without using make, to see if your source code compiles correctly?
Addendum
Perhaps your include path is different when you run make. There is a debug/trace option for make that dumps all of its macros (but I don't remember what it is off the top of my head), which might help.