after trying to cross compile a program for a week i gave up and now im trying to compile it directly on the friendlyarm running qtopia 2.2.0, but when i run make i am getting some strange errors. Can some one shine some more light on the and maybe point me in the right direction on how to fix the problem?
the make output:
/sdcard/images/makef # make
make: Warning: File `Makefile' has modification time 2.2e+04 s in the future
gcc -c -o obj/main.o main.c -I./
gcc -c -o obj/serial.o serial.c -I./
gcc -c -o obj/fb.o fb.c -I./
gcc -c -o obj/menu_main.o menu_main.c -I./
gcc -c -o obj/timer.o timer.c -I./
gcc -c -o obj/cmdin.o cmdin.c -I./
cmdin.c: In function 'processcmd':
cmdin.c:64: warning: format '%f' expects type 'float *', but argument 4 has type 'int *'
gcc -c -o obj/buzzer.o buzzer.c -I./
gcc -c -o obj/statemachine.o statemachine.c -I./
gcc -c -o obj/inout.o inout.c -I./
gcc -c -o obj/network.o network.c -I./
gcc -c -o obj/text_file_input.o text_file_input.c -I./
gcc -c -o obj/text_file_input_oven.o text_file_input_oven.c -I./
gcc -o main obj/main.o obj/serial.o obj/fb.o obj/menu_main.o obj/timer.o obj/cmdin.o obj/buzzer.o obj/statemachine.o obj/inout.o obj/network.o obj/text_file_input.o obj/text_file_input_oven.o -I./ -lgd -lrt
/usr/bin/ld: skipping incompatible /usr/lib/gcc/arm-linux-gnueabi/4.4.1/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/gcc/arm-linux-gnueabi/4.4.1/librt.a when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/gcc/arm-linux-gnueabi/4.4.1/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/gcc/arm-linux-gnueabi/4.4.1/librt.a when searching for -lrt
/usr/lib/gcc/arm-linux-gnueabi/4.4.1/../../../librt.a(timer_create.o): In function `timer_create':
timer_create.c:(.text+0xd4): undefined reference to `pthread_once'
/usr/lib/gcc/arm-linux-gnueabi/4.4.1/../../../librt.a(timer_routines.o): In function `timer_helper_thread':
timer_routines.c:(.text+0xfc): undefined reference to `pthread_create'
/usr/lib/gcc/arm-linux-gnueabi/4.4.1/../../../librt.a(timer_routines.o): In function `__start_helper_thread':
timer_routines.c:(.text+0x1a0): undefined reference to `pthread_attr_setstacksize'
timer_routines.c:(.text+0x1e4): undefined reference to `pthread_create'
timer_routines.c:(.text+0x228): undefined reference to `pthread_atfork'
collect2: ld returned 1 exit status
make: *** [main] Error 1
/sdcard/images/makef #
Also how can i get if this message:
make: Warning: File `Makefile' has modification time 2.2e+04 s in the future
i tried
touch *.*
but that didn't help
make: Warning: File `Makefile' has modification time 2.2e+04 s in the
future
Your clocks on the system you are compiling on and the system that generated the files are out of sync. You should fix that (in another answer is mentioned a workaround using touch, but this is only a good idea if the "other computer" is running the wrong time - if your system you are compiling on is running the wrong time, then you should fix the time on the current system - ideally using ntp (network time protocol) to set your time on both systems from a network source at boot or similar - that way, you don't have to worry about them going out of phase either [a PC system clock will drift between 1 and 30 seconds in a month, depending on the actual hardware used].
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/4.4.1/librt.so when searching for -lrt
These messages are harmless as long as the system is able to find some librt that "is compatible", and it seems like it does, since we get this.
/usr/lib/gcc/arm-linux-gnueabi/4.4.1/../../../librt.a(timer_routines.o)
The following indicates that libpthread is not being linked (in the right place)
timer_create.c:(.text+0xd4): undefined reference to `pthread_once'
You need to use -lpthread on your linker line - after -lrt, since librt is what is using pthread functions. Note that libraries are sensitive to order (and sometimes you even need to give the same library twice, because there are cyclic dependencies)
That message is usually an indication that some of your files have modification times later than the current system time. A possible solution is to "touch" every file in the source tree in order to update timestamps: go to the root of the subtree an do "find . -exec touch {} \; "
Then clean your project, delete all build files and retry compilation.
It seems that You have also forgotten to link libpthread. You should have posix libraries and link your project to libpthread.
Related
I'm trying to build some example c++ code that use boost library. I use this as reference example of static linking.
And everything is fine when I build with dynamic libs.
g++ -Wall -std=c++0x -O3 -Wfatal-errors -I/usr/include/boost/include -c -o src/main.o src/main.cpp
g++ -Wall -std=c++0x -O3 -Wfatal-errors -I/usr/include/boost/include -c -o src/ThreadExample.o src/ThreadExample.cpp
g++ -Wall -std=c++0x -O3 -Wfatal-errors -I/usr/include/boost/include -c -o src/Utils.o src/Utils.cpp
g++ src/main.o src/ThreadExample.o src/Utils.o -lboost_thread -lboost_filesystem -lboost_system -lboost_timer -o ThreadExampleBinary
But when I use static libs I get lots of undefined reference errors:
g++ -Wall -std=c++0x -O3 -Wfatal-errors -I/usr/include/boost/include -c -o src/main.o src/main.cpp
g++ -Wall -std=c++0x -O3 -Wfatal-errors -I/usr/include/boost/include -c -o src/ThreadExample.o src/ThreadExample.cpp
g++ -Wall -std=c++0x -O3 -Wfatal-errors -I/usr/include/boost/include -c -o src/Utils.o src/Utils.cpp
g++ -static src/main.o src/ThreadExample.o src/Utils.o -lboost_thread -lboost_filesystem -lboost_system -lboost_timer -o ThreadExampleBinary
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_timer.a(cpu_timer.o): In function `boost::timer::cpu_timer::start()':
(.text+0x7fd): undefined reference to `boost::chrono::steady_clock::now()'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_timer.a(cpu_timer.o): In function `boost::timer::cpu_timer::stop()':
(.text+0x94c): undefined reference to `boost::chrono::steady_clock::now()'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_timer.a(cpu_timer.o): In function `boost::timer::cpu_timer::elapsed() const':
(.text+0xa59): undefined reference to `boost::chrono::steady_clock::now()'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_timer.a(cpu_timer.o): In function `boost::timer::cpu_timer::resume()':
(.text+0xb60): undefined reference to `boost::chrono::steady_clock::now()'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_timer.a(cpu_timer.o): In function `boost::timer::auto_cpu_timer::auto_cpu_timer(std::ostream&, short)':
(.text+0xca5): undefined reference to `boost::chrono::steady_clock::now()'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libboost_timer.a(cpu_timer.o):(.text+0xd4e): more undefined references to `boost::chrono::steady_clock::now()' follow
collect2: error: ld returned 1 exit status
make: *** [ThreadExampleBinary] Error 1
Seems this can be fixed adding additional -lboost_chrono library.
But why it works in dinamic setting?
With static linking, you have to also statically link to any libraries depended on by the libraries you are linking to.
The difference is that shared libraries have an entry in the ELF header, called NEEDED that lists other shared libraries that are to be included when you link in this one.
You can see them with this command:
$ objdump -p /usr/lib/libboost_timer.so | grep NEEDED
NEEDED libboost_chrono.so.1.60.0
NEEDED libboost_system.so.1.60.0
NEEDED librt.so.1
NEEDED libstdc++.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
But for static libraries there is no such system, as they are simply collection of object files.
It is worth noting that the NEEDED entry in the shared objects are entirely optional, and if they are not available, then they will behave exactly like the static ones. But most shared libraries include them.
Many libraries use the pkg-config infrastructure to provide the full command line needed, but AFAIK boost is not one of them.
How to automate this process? Well, you do not. You just include what is needed and follow the linker errors to discover further needs.
You can find which static library includes a symbol with something like:
$ nm --print-file-name --defined-only --demangle /usr/lib/*.a 2> /dev/null | \
grep -q 'boost::chrono::steady_clock::now()'
/usr/lib/libboost_chrono.a:chrono.o:0000000000000090 T boost::chrono::steady_clock::now()
But why it works in dinamic setting?
Most of my make files have the following notes (from when I found the answer back when I needed it ... sorry, I don't know where I found it.)
Note - when a build using '-l' finds the .so version of that library (so - shared object) and the same .a archive is also there, g++ prefers the .so over the .a.
However, you can still achieve static link by fully specifying the path to .a.
Example:
$(CC) $(CC_FLAGS) $< /usr/local/lib/libboost_chrono.a -o $# ...
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sometimes, archive code refers to symbols in yet another archive.
i.e. -lyyy_i686 uses some function from -lxxx_i686, and xxx was listed first in the build command. It is possible that a symbol might remain unresolved and the linker fails.
When this happens, try adding xxx a second time to the end of the archive list
from: -lxxx_i686 -lyyy_i686 -lrt -pthread
becomes -lxxx_i686 -lyyy_i686 -lrt -pthread -lxxx_i686
^^^^^^^^^_____________________________^^^^^^^^^^
The preceeding presumes only .a libraries are findable (no xxx.so)
Another alternative, you can command the linker to search an archive multiple times
-lyyy_i686 -lrt -pthread -(-lxxx_i686-)
tell gcc to link this library as many times as needed __^^__________^^
Again, only .a is findable
Finally, if you choose to link with the .so, note that this does not pull in the entire lib into the current build target. Instead, at runtime, the .so is loaded into memory, if it is not already there. This happens after the program starts. For most applications, this is considered a 'small' start-up performance hit as the program adjusts its memory map (automagically behind the scenes). I believe I once found that the app itself can control when to load the .so.
The use of .so pulls in the entire library to memory (if not already installed). Thus, there would not be any missing symbols, in my xxx vs yyy scenario above, the .so pulls all the symbols, whether used or not.
And once again, when trying to load xxx using "-lxxx_i686", the linker prefers to pull in libxxx_i686.so even when the libxxx_i686.a is in the same directory.
I am compiling using arm-linux-gnueabi-g++ version 4.7.3.
I have the arm-linux-gnueabi libraries installed at location:
/usr/arm-linux-gnueabi/lib, it contains libdl.a, libdl.so, libdl.so.2,
and libdl-2.19.so.
libdl.so links to libdl.so.2 which links to libdl-2.19.so.
I am trying to link against the dl library (see command string below), but I always get the undefined reference errors.
arm-linux-gnueabi-g++ -I. -I../ -I../Comms/Linux -Wall -DLINUX -fpic -o ../../work/MyProgram main.o
-L../../work -L/usr/arm-linux-gnueabi/lib -lComms -lConsole -lUtilities -ldl
../../work/libUtilities.so: undefined reference to `dlsym'
../../work/libUtilities.so: undefined reference to `dlopen'
collect2: error: ld returned 1 exit status
If I compile using g++ 4.8.2 using the following commend then my program compiles, links, and executes fine.
g++ -I. -I../ -I../Comms/Linux -Wall -DLINUX -fpic -o ../../work/MyProgram main.o
-L../../work -lComms -lConsole -lUtilities -ldl
Obviously it can't find the libdl.so library; I thought that by adding the path to the location of the appropriate library by using the -L flag would fix the problem, but it didn't.
What am I missing with the ARM compiler command?
Well, I found the answer, I needed -Wl,--no-as-needed flag before the -ldl. I had run across this flag before I asked the question, but apparently mistyped it because it hadn't worked for me.
I don't understand why the flag is needed, but the code does finish linking now.
A SO user here says that it has to do with recent (2013 as of the user's post) versions of gcc linking to --as-needed.
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.
Recently I need to use zlib in programming on Ubuntu and here I have a problem.
I wrote a small program to test zlib functions and I built it in Eclipse.
I found it can be compiled but there were some linking errors like this:
main.cpp:27: undefined reference to `compress'
main.cpp:38: undefined reference to `uncompress'
What should I do with this? If this is because there is no library file?
Can anyone give some help? Thanks a lot!
MOODY_Y
Plus, here are my building info:
11:59:08 **** Build of configuration Debug for project test_zlib ****
make all
Building file: ../main.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
Finished building: ../main.cpp
Building target: test_zlib
Invoking: GCC C++ Linker
g++ -o "test_zlib" ./main.o
./main.o: In function `main':
/home/hyq/workspace/test_zlib/Debug/../main.cpp:27: undefined reference to `compress'
/home/hyq/workspace/test_zlib/Debug/../main.cpp:38: undefined reference to `uncompress'
collect2: ld return 1
make: *** [test_zlib] error 1
11:59:10 Build Finished (took 1s.715ms)
Try:
sudo apt-get install zlib1g-dev
Also, use -lz on the compile/link command.
You need to link youe source to zlib.Build your code as follows
gcc main.cpp -lz
I have to implement the machine translation system hence I am planning use moses but I facing following error while executing make command on Cygwin:
Administrator#diebold-69b7050 /cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses/scripts/training/memscore$ make
make all-am
make[1]: Entering directory `/cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses
scripts/training/memscore'
g++ -I/usr/include -Wall -ffast-math -ftrapping-math -fomit-frame-pointer -g -O2 -o memscore.exe phrasetable.o memscore.o scorer.o lexdecom.o -lz -lm
phrasetable.o: In function `_ZlsRSoRK15PhraseAlignment':
/cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses/scripts/training/memscore/phrasetable.cpp:111: undefined reference to `boost::system::system_category()'
phrasetable.o: In function `__tcf_0':
/cygdrive/c/JT/NewSetup/Moses/moses-2010-08-13/moses/scripts/training/memscore/datastorage.h:31: undefined reference to `boost::system::system_category()'
phrasetable.o: In function `_ZN14PhrasePairInfo12realloc_dataEj':
/usr/include/boost/pool/simple_segregated_storage.hpp:97: undefined reference to `boost::system::system_category()'
phrasetable.o: In function `_ZNK14PhrasePairInfo14get_alignmentsEv':
Please don't give me suggestion like linker error because I am completely fad up of trying linker option.
I think, I have some Cygwin->Boot library problem. Can you suggest me where I am wrong?
You are mssing -lboost_system on your compilation commands.
Some of the boost libraries are header only. Others need to be compiled. And the libraries sometimes depend on each other. In this case you are using some boost library which needs -lboost_system. Add it so that it gets linked with your project.
and it should be on this line. Where linking is done
g++ -I/usr/include -Wall -ffast-math -ftrapping-math -fomit-frame-pointer -g -O2 -o memscore.exe phrasetable.o memscore.o scorer.o lexdecom.o **-lboost_system** -lz -lm