I have been using gtests for unit testing a personal project. Last week I upgraded to the LTS version of Linux Mint. Unfortunately, after that event, I haven't been able to compile my project due to gtests linking problems.
The following error is being issued:
/usr/bin/x86_64-linux-gnu-ld: build/tests/policies/roundrobin_tests.o: undefined reference to symbol '_ZN7testing4TestC2Ev'
/home/myuser/Documents/googletest-release-1.8.0/googletest/libgtest.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I have generated both libgtest.so and libgtest_main.so through CMake 3.10.2. The gtest version is the release-1.8.0, the same I used to have before.
Those libraries are located in /usr/lib and the corresponding include folder has also been copied to /usr/include. I made sure that this location is in my ld path and that is not the problem.
My compiler is g++ v7.3.0 and the command Im using to compile the testes is:
g++ -std=c++14 -Wall -O3 -Iinclude build/tests/policies/roundrobin_tests.o -lgtest_main -pthread -o bin/policies/roundrobin_tests
I have tried altering the order of the elements in the command, explicitly adding -L/usr/lib and -I/usr/include without luck. A funny fact is that if I take off the -pthread flag, the error is still the same.
The same command was used before and the only difference is the compiler version I am using now as I used g++ 5.4.0 before. Any insights on how to solve this?
edit: Just tested the same process with g++ 5.4.0 and CMake 3.5 and the same problems ocurred.
Related
I am trying to compile for a gd32v chip using gcc(the riscv version on the arch community repo).
Compiling seems to work fine, however when trying to link the objects into an elf file, I get the error:
Linking ELF target: main.elf
riscv64-linux-gnu-g++ #_linker_flags -o main.elf ../../bmptk-RISC-V/targets/risc_v/gd32v/gd32vf103xb_boot.o hwlib.o main.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Source/gd32vf103_rcu.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Source/gd32vf103_gpio.o ../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/system_gd32vf103.o bmptk_heap_none.o bmptk_fixed_size_stack.o -Os -Tmain.ld
/usr/lib/gcc/riscv64-linux-gnu/10.2.0/../../../../riscv64-linux-gnu/bin/ld: /usr/lib/gcc/riscv64-linux-gnu/10.2.0/../../../../riscv64-linux-gnu/lib/libstdc++.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make: *** [../../bmptk-RISC-V/Makefile.inc:1498: main.elf] Error 1
In this make rule, I am using a file '_linker_flags' for my linker flags, to keep the terminal clean during compilation. The contents of this file are as follows:
-march=rv32imac -mabi=ilp32 -Os -fdata-sections -ffunction-sections -I../../bmptk-RISC-V/targets/risc_v/ -I../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral -I../../bmptk-RISC-V/targets/risc_v/GD32VF103_standard_peripheral/Include -I../../bmptk-RISC-V/targets/risc_v/RISCV/drivers -I../../bmptk-RISC-V/targets/risc_v -I/usr/include -I/usr/include -I../../hwlib-RISC-V/library -I../../Catch2/single_include -I../../Catch2/single_include/catch2 -I../../boost_1_69_0 -I../../bmptk-RISC-V -I../../bmptk-RISC-V/targets -I../../bmptk-RISC-V/targets/risc_v -I../../bmptk-RISC-V/targets/risc_v/RISCV -I../../bmptk-RISC-V/targets/risc_v/RISCV/drivers -DHWCPP_FAKE_OSTREAM -DBMPTK_TARGET=gd32vf103v -DBMPTK_TARGET_gd32vf103v -DHWLIB_TARGET_gd32vf103v -DHWCPP_TARGET_gd32vf103v -DGF_TARGET_gd32vf103v -DBMPTK_CHIP=gd32vf103v -DBMPTK_CHIP_gd32vf103v -DBMPTK_XTAL= -DBMPTK_BAUDRATE=38400 -DHWLIB_BAUDRATE=38400 -DGODAFOSS_BAUDRATE=38400 -DGF_BAUDRATE=38400 -DBMPTK_VERSION=V04_00_work_in_progress_2020_05_23 -DBMPTK_EMBEDDED -lgcc -Wl,-Map,main.map -Wl,--gc-sections -Wl,-fatal-warnings
I'm not familiar with this error, does anyone know what I would have to look into to fix this?
EDIT:
I asked a teacher at school and they told me that the problem most likely arised from using a mismatching linker and compiler, or that some object files weren't cleaned when calling make. I made sure all objects were deleted before compiling and made sure the compiler and linker were the same.
They should be the same. I am running riscv64-linux-gnu-ld version 2.35 and riscv64-linux-gnu-g++ version 10.2.0. Both are from the arch community repository.
To see exactly the mapping/switches of the libraries supported by your compiler you can use : riscv64-linux-gnu-g++ -print-multi-lib. If you compiler was compiled with multilib enabled you can choose an rv32 libs without hard float otherwise it will not link also since you are compiler for rv32imac.
If your compiler was build without the multlib option you have two option:
Compile with -nostdlib and provide the needed file to the linker crt, libc libgcc ... or you can get a compiler which was build with multilib enabled.
I read V8 hello world example, and follow the steps in the document to build v8 successfully.
But when I compile the example code, link error occured. Here comes my computer detail and error prompts.
OS Ubuntu 13.10 amd64
GCC (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Compile command:
g++ -Iinclude hello_world.cc -o hello_world -Wl,--start-group out/native/obj.target/{tools/gyp/libv8_{base.x64,snapshot},third_party/icu/libicu{uc,i18n,data}}.a -Wl,--end-group -lrt
Error prompts
/usr/bin/ld: /home/leon/Documents/v8/v8/out/native/obj.target/v8_base.x64/src/platform/mutex.o: undefined reference to symbol 'pthread_mutexattr_settype##GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The error suggests that you need to add the pthread library to your link command. Just append -lpthread.
(It's a bit odd that it identifies exactly which library you need, then tells you it refuses to use it because you didn't list it on the command-line...)
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 downloaded the libcurl curl-7.34.0-devel-mingw32.zip from http://curl.haxx.se/gknw.net/7.34.0/dist-w32/curl-7.34.0-devel-mingw32.zip.
I use Eclipse Kepler with MinGW as the toolchain (GCC compiler). I created html.cpp and then test the code from the example http://curl.haxx.se/libcurl/c/simple.html:
I included the headers:
#include<iostream>
#include<curl/curl.h>
using namespace std;
There are 5 cURL functions. Only 2 of them (curl_easy_init,curl_easy_setopt)are said to be 'undefined reference'.
The compiler message:
Info: Internal Builder is used for build
g++ -O3 -Wall -c -fmessage-length=0 -o html.o "..\\html.cpp"
g++ -static-libgcc -static-libstdc++ -o HTML.exe html.o
html.o:html.cpp:(.text.startup+0x12): undefined reference to `_imp__curl_easy_init'
html.o:html.cpp:(.text.startup+0x1e): undefined reference to `_imp__curl_easy_setopt'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: html.o: bad reloc address 0x1e in section `.text.startup'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
The other 3 functions said to be fine:
curl_easy_perform
curl_easy_strerror
curl_easy_cleanup
I have tried to set to properties to tell the MinGW linker to include the headers and library files. The same situation as the above or the compiler simply says the .a files not found. Adding -lcurl or -DCURL_STATICLIB to the linker's flag is useless as well.
I have also tried to copy the libraries(.a files) and the headers(.h files) of libcurl to the folders bin, include and lib inside C:\MinGW and C:\gcc-4.8.1. It turns out to be no change.
Sadly, the first challenge of using cURL is not coding but the compilation. How can I solve this problem?
Thanks you guys!
I'm trying to build a specific program on Ubuntu 12.04 64 bit.
The program needs to be compiled 32 bits.
I installed the ia32-libs and gcc-multilib packages.
I managed to compile it on 3 different computers, but on this one, it fails with a weird error.
for some reason, libm.so is not picked up correctly, or something is wrong with the library.
This is the actual compilation line that fails as it was extracted from the Makefile.
gcc -o x86_32_obj/foo x86_32_obj/foomain.o -m32 -fPIC -fno-stack-protector -lc -lgcc -lm -lpthread -lrt -lstdc++ ../libfoo/lib/./libfii.x86_32.a
This is the output
/usr/bin/ld: ../libfoo/lib/./libfoo.x86_32.a(NK_Meas.o): undefined reference to symbol 'expf##GLIBC_2.0'
/usr/bin/ld: note: 'expf##GLIBC_2.0' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[1]: *** [foo] Error 2
make: *** [foo] Error 2
I have seen errors such as this in relation to the linking order. It may be possible to address the error by placing the libm linking directive at the very end of your linking configuration.
These interdependencies are very much system dependent, which is probably why the same command works on other systems.
Found the problem.
Apparently, the library file I was linking against was compiled using a different version of GCC.
I don't know how exactly it's related, but once I replaced the gcc compiler to the one used with the library it worked.