I'm trying to compile a simple "Hello World" program in Linux using Eclipse, but I always get this:
Building target: hello
Invoking: GCC C++ Linker
g++ -o "hello" ./src/hello.o
./src/hello.o: file not recognized: File truncated
collect2: ld returned 1 exit status
make: *** [hello] Error 1
**** Build Finished ****
Does anyone have an idea what the problem is?
Just remove the object file.
This error most likely appeared after the previous build was interrupted and object file was not generated completely.
Just as an info if someone comes around here.
Another problem (with the same error) could be, that you are using ccache for faster compilation. In this case, the corrupt *.o file is there as well. So for that reason you have to clean the cache with
ccache -C (note the upper case C!)
Wasted me hours the first time ;-)
I think
g++ -o "hello" ./src/hello.o
should be ./src/hello.(c | cpp | cc depending on your language type)
Related
I am trying to compile this C++ code in my Linux box using g++ but it fails with the following error:
enigma/Enigma# g++ -I . main.cpp -o main
In file included from machine.h:14:0,
from tests.h:13,
from main.cpp:10:
plug.h:13:2: warning: #import is a deprecated GCC extension [-Wdeprecated]
#import "util.h"
^~~~~~
/tmp/ccxyoEC2.o: In function `main':
main.cpp:(.text+0x10): undefined reference to `test_machine_encode_decode()'
collect2: error: ld returned 1 exit status
The error indicates that the compiler cannot find the tests.h file present in the same folder. How can I compile and run this code?
I now understand that I needed to link the object files together, I did so using:
g++ -c *.cpp
g++ *.o -o enig
It still does not work though, the resulting binary executes with ./enig but is broken and does not function as intended:
Entire encoded message: TZQA
Decoding now...
Entire decoded message: AHOJ
Entire encoded message: HBIU
Decoding now...
Entire decoded message: AHOJ
Entire encoded message: ZSNE
Decoding now...
Entire decoded message: AHOJ
Entire encoded message: ICRH
It just keeps encoding and decoding those random texts as opposed to the functionality mentioned on the git page I shared above.
Anything I'm missing?
The error indicates that the compiler cannot find the tests.h file present in the same folder.
No, it doesn't. In fact, the compiler successfully compiled main.cpp.
The error indicates that the linker cannot find test_machine_encode_decode. This is hardly surprising, since test_machine_encode_decode is defined in test.cpp. You have to link the object files of main.cpp and test.cpp to get a complete executable.
If you look at the actual code, you'll see that main only calls the test_machine_encode_decode() Unit-test. You'll have to implement the functionality from the readme yourself or you search through the git history and try to find out, if the program actually worked in the past.
I downloaded a software framework from the Data Prefetching Championship website (http://www.jilp.org/dpc/) and installed on a computer with the Ubuntu OS, 64 bit. I followed all of the instructions for unpacking the compressed file, and entered the "make" command to compile and this is what I received:
g++ -Wl,-u,main -g -shared -Wl,-Bsymbolic -Wl,--version-script=/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/source/include/pintool.ver -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/Lib/ -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/ExtLib/ -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/extras/xed2-intel64/lib -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/intel64/lib -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/intel64/lib-ext -o bin/CMPsim.usetrace ./bin/libCMPsim64.a ./src/prefetch/sample_prefetcher.o -lpin -lxed -ldwarf -lelf -ldl /usr/lib/x86_64-linux-gnu/libz.a
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libz.a(gzio.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/x86_64-linux-gnu/libz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [CMPsimpref64] Error 1
The problem, I believe, is with the libz.a file. Help?
I do not know how you compile this application, but you should add -fPIC to the compilation flags (CFLAGS and CXXFLAGS) of C/C++ files and recompile the application.
I also faced same problem mentions above but I am able to solved it with scientific linux 5.4 with gcc 4.1 configuration and I did one mistake when we have to set path up to prefetch kit. There was '$' sign which we have to remove while setting path for that PREF_KIT
I have been trying to compile and link Qt5, which means I have been messing with some ldconfig and include path defaults that I don't completely understand. I will do my best to limit my question to a very specific one, as my priority is fixing my compiler.
I have used a command to try
`gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.7
/usr/include/c++/4.7/x86_64-linux-gnu
/usr/include/c++/4.7/backward
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include
End of search list.
There is a problematic line at the beginning, about ignoring a non-existent directory when searching for the header. Unfortunately, this is exactly where g++ thinks it's a good idea to look for crt1.o, which I assume is some sort of binary that morphs the main() function into an executable:
g++ -Isrc --std=c++11 -g -c -o src/tissuecell.o src/tissuecell.cpp
g++ -Isrc --std=c++11 -g -c -o src/analyze.o src/analyze.cpp
g++ -o TissueCells src/tissuecell.o src/analyze.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
My compiler has not done this until a few hours ago (previously, it would compile!), and what comes to mind in terms of "irreversible commands" that I typed was a single:
sudo ldconfig
Can anyone get me out of this terrible pit of linking and compilation problems, and remove this pesky line from my include path?
Some questions that you might also be able to answer that would make me very happy:
How do I view & edit the paths that my compiler searches for includes? (Not -I)
How do I view & edit the paths that my compiler searches for libraries? (Not -L, and ld should be able to find the libraries as it needs them)
What relation does ld have to this whole process, and is there a way to pass ld some flags through my g++ call (for example, -rpath)?
Oh gosh, this is embarrassing. My problem was that I did not fix my Makefile after giving up on the new build; the error was coming from a lack of main() function in my codebase.
The following command allowed me to test my compiler for internal errors:
echo "int main() { return 0; }" > /tmp/test.c; gcc -v /tmp/test.c
I pulled back to an old commit on my git, and got my code to compile, which served as a good double-check on my compiler's sanity.
First of all you can run gcc(g++) with "-v" option, for example:
echo "int main() { return 0; }" > /tmp/test.c
gcc -v /tmp/test.c
You find in ouput the things like:
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4
plus
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include-fixed
/usr/include
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../:/lib/:/usr/lib/
and many other stuff.
The second variant you can use "strace -f" in front of your command, grep ouput with pattern open to find out where and what file is used.
I've been working on a c++ project for a while now, but would like to port it over to my arm processor. I already have all of my cross-compile tools (I'm using CodeSourcery) and thought I could just change my makefile to point to that compiler. It compiles fine using the default g++, but When try a make pointing to the cross-compiler I get relocation errors:
/home/oryan/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.2/../../../../arm-none-linux-gnueabi/bin/ld: ServerSocket.o: Relocations in generic ELF (EM: 3)
ServerSocket.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [simple_server] Error 1
It seems like I don't have a proper link set up or it's pointing to a wrong location. I'm not that familiar with makefiles and am probably missing something obvious. The makefile I've been using is from http://tldp.org/LDP/LG/issue74/tougher.html with the client side removed:
# Makefile for the socket programming example
#
simple_server_objects = ServerSocket.o Socket.o simple_server_main.o
all : simple_server
simple_server: $(simple_server_objects)
/home/matt/CodeSourcery/bin/arm-none-linux-gnueabi-g++ -o simple_server $(simple_server_objects)
Socket: Socket.cpp
ServerSocket: ServerSocket.cpp
simple_server_main: simple_server_main.cpp
clean:
rm -f *.o simple_server
Right now I am manually compiling each file and it works great, but I'd like to further my understanding here.
Thanks!
The problem is you've set your makefile up to link with the new g++ but you haven't changed the compiler you're using to build the objects in the first place.
The easiest way to fix this is to set environment CXX to the next compiler, i.e.
export CXX=/home/matt/CodeSourcery/bin/arm-none-linux-gnueabi-g++
or just set it for a given make by adding CXX=... to the command line.
You'll need to make clean first but you'll then use the correct compiler for both the compile and link.
You could also specify a new how-to-compile-C++ files rule in your makefile to specify the new compiler but the environment variable is easier:
.cc.o:
/home/.../g++ $(CPPFLAGS) $(CXXFLAGS) -c
The problem is because of these three rules:
Socket: Socket.cpp
ServerSocket: ServerSocket.cpp
simple_server_main: simple_server_main.cpp
First of all, the left-hand side of the rule should be the object file I guess, so should have the .o suffix.
The second problem, and most likely the root of your problem, is that there is no command to compile the source files, which means that make will use the default compiler and not your cross-compiler.
On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.