While compiling my project with gcov support I am facing the below error
Following are flags information i have while compiling
compiler flags:
CXXFLAGS="-Wno-deprecated -g -ggdb -fprofile-arcs -ftest-coverage -fPIC"
linker options:
LINK_CMD="gcc -fprofile-arcs -fPIC"
Following are version information:
gcc version:
gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)
gcov version:
gcov (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
error:
hidden symbol `__gcov_init' in /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcov.a(_gcov.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
Could you please help me to get away from this problem?
I have been able to solve this problem in my own code using these steps:
Make clean (remove all of my .o and lib files).
Ensure every source file has the correct options (-fprofile-arcs -ftest-coverage).
Ensure every shared library the source files are compiled into specify -lgcov
Ensure I link the executable with -lgcov.
See also this answer and this blog post.
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 want to develop a small program that checks which polygons from a shapefile intersect a given rectangle. This program is to be used in a website (with PHP's exec() command). The problem is, my webserver cannot install GDAL, for reasons unknown to me. So I can't link to the shared libraries. Instead, I must link to static libraries, but these aren't given.
I've downloaded the GDAL source code from here (2.3.2 Latest Stable Release - September 2018), and followed the build instructions from here. Since I already have GDAL working on my Debian, and don't want to mess with it, I followed the "Install in non-root directory" instructions, with some adjusts from the last item in the "Some caveats" section:
cd /home/rodrigo/Downloads/gdal232/gdal-2.3.2
mkdir build
./configure --prefix=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/ --without-ld-shared --disable-shared --enable-static
make
make install
export PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/bin:$PATH
export LD_LIBRARY_PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib:$LD_LIBRARY_PATH
export GDAL_DATA=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/share/gdal
/usr/bin/gdalinfo --version
build/bin/gdalinfo --version
The first /usr/bin/gdalinfo --version gives 2.1.2 (the previous installed version). The second, build/bin/gdalinfo --version, gives 2.3.2 (the version just built).
By now, my program only uses the ogrsf_frmts.h header, which is in /usr/include/gdal/ or /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/include/ directory, depending on the build. There's no ogrsf_frmts.a file, but only a libgdal.a. Is this the file I should be linking against? If so, how? I've tried so far:
gcc geofragc.cpp -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
but nothing works. What am I missing?
EDIT
The second trial (gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a) is giving the following error:
/usr/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libgdal.a(gdalclientserver.o): In function `GDALServerSpawnAsync()':
(.text+0x1f5e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
You can use the gdal-config program to get correct options for compilation and linking. This program is a part of the GDAL library and it has its own options:
hekto#ubuntu:~$ gdal-config --help
Usage: gdal-config [OPTIONS]
Options:
[--prefix[=DIR]]
[--libs]
[--dep-libs]
[--cflags]
[--datadir]
[--version]
[--ogr-enabled]
[--gnm-enabled]
[--formats]
You have to make sure this program is on your search path, or you can create an alias - for example:
alias gdal-config='/home/rodrigo/Downloads/gdal232/gdal-2.3.2/bin/gdal-config'
Now your compilation and linking command becomes the following one:
g++ `gdal-config --cflags` geofragc.cpp `gdal-config --libs` `gdal-config --dep-libs`
You have to use the g++ compiler to link with C++-built libraries.
Another option is to create a Makefile with these lines:
CXXFLAGS += ${shell gdal-config --cflags}
LDLIBS += ${shell gdal-config --libs}
LDLIBS += ${shell gdal-config --dep-libs}
geofragc: geofragc.cpp
and just call make with this Makefile.
I hope, it'll help.
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.
I am using the command:
g++ --std=c++11 -fPIC -Iincludes parser.cpp lib/main-parser.o lib/lib.a
To compile a C++ program on Debian 9. But I am getting the below error message:
/usr/bin/ld: lib/lib.a(csdocument.o): relocation R_X86_64_32 against '.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
I have already seen the thread:
Compilation fails with "relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object"
However, I have tried adding the -fPIC argument however it strangely gives the same error message, along with "recompile with -fPIC"
Any ideas would be appreciated. I have tried compiling this on my University's RedHat systems and it works fine there. I'm thinking it could be a missing dependency, but I've been unable to find any answers.
Thanks in advance
As it seems gcc is trying to produce a position-independent executable ("shared object" is the hint), tell it not to:
g++ --std=c++11 -no-pie -Iincludes parser.cpp lib/main-parser.o lib/lib.a
It seems that g++ produces position-independent executables by default on your system. Other systems would require -pie to do so. Using -no-pie should create a "regular" (position dependent) executable.
(The error is a result of trying to link an object file that was compiled as non-position-independent into an executable that is supposed to be position-independent).
/usr/bin/ld: lib/lib.a(csdocument.o): relocation R_X86_64_32 against '.rodata' \
can not be used when making a shared object; recompile with -fPIC
This linker error is telling you that the object file csdocument.o in the
static library lib/lib.a is not Position Independent Code and hence
cannot be linked with your PIE program. So you need to recompile the source
files of lib/lib.a with -fPIC, then rebuild the static library, then link
it with your PIE program. If you don't have control of the libary sources
then request a PIC build from its supplier.
(Others have questioned why you should need to build a PIE target at all
since it's not a shared library. In Debian 9, GCC produces PIE executables
by default,
whether programs or shared libraries. The same goes for Ubuntu as of 17.04. )
Adding this worked for me.
g++ --std=c++11 -no-pie
I also added the -fPIC to compile flag.
I have a Linux-based application, running under Ubuntu 12.04 LTS, that compiled, linked, and ran with no problem.
I recently upgraded my Ubuntu to 14.04 LTS and encountered problems compiling and linking the app.
The compilation problems were solved by manually modifying my local copy of Boost 1.48 in two files (include/boost/config/stdlib/libstdcpp3.hpp and include/boost/thread/xtime.hpp). At this point the app compiled successfully.
The problem I have is that the linkage fails with the error message:
c++: error: unrecognized command line option ‘-Wl’
I use CMake to enable compiling the app on multiple platforms. Here is the linker script generated by CMake. Note that the "-Wl" options are now inexplicably unrecognized by /usr/bin/c++:
/usr/bin/c++
-fno-stack-protector
-g
-Wl
CMakeFiles/Project.dir/main.cpp.o
CMakeFiles/Project.dir/TestCallback.cpp.o
CMakeFiles/Project.dir/utils.cpp.o
CMakeFiles/Project.dir/Request1.cpp.o
CMakeFiles/Project.dir/Response1.cpp.o
CMakeFiles/Project.dir/TextChatRequest.cpp.o
CMakeFiles/Project.dir/TextChatResponse.cpp.o
-o
/home/user/private/Project/Project_Release_1_2_Codename/Build/bin/Debug/Project
-L/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib
-L/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib
-L/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib
-L/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug
-L/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
-rdynamic
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libAPI.a
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libInternals.a
-lboost_thread
-lboost_system
-lboost_filesystem
-lboost_program_options
-ltaglib
-lJSON
-lpthread
-Wl,-Bstatic
-lsqlite3
-Wl,-Bdynamic
-ldl
-Wl,-rpath,/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib:/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib:/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib:/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug:/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
Here is version information for the software I'm using:
Ubuntu:
14.04.1 LTS (trusty)
c++ compiler/linker:
(Ubuntu 4.8.2-19ubuntu1) 4.8.2
CMake:
Version 2.8.12.2
Why doesn't the linker recognize "-Wl" commands? Did my upgrade to 14.04 LTS modify the linker software libraries? How can I get my app back up and linking?
On line 4 of the command you have -Wl without any actual linker options.
https://gcc.gnu.org/gcc-4.7/porting_to.html
Right at the top of this page is the following:
Earlier releases did not warn or error about completely invalid
options on gcc/g++/gfortran etc. command lines, if nothing was
compiled, but only linking was performed. This is no longer the case.
For example,
gcc -Wl -o foo foo.o -mflat_namespace
Now produces the following error
error: unrecognized command line option ‘-Wl’
error: unrecognized command line option ‘-mflat_namespace’
Invalid options need to be removed from the command line or replaced by something that is valid.
12.04 LTS packaged GCC 4.6, you've now jumped to 4.8 and -Wl on its own is no longer a valid option (or rather it never was, GCC is just more pedantic now).
As mentioned by others previously, it indeed turned out that my CMake script was injecting a lone, solitary, seemingly unnecessary "-Wl" via the CMAKE_EXE_LINKER_FLAGS setting:
if(LINUX)
set(THIRDPARTY_LIBS boost_thread boost_system boost_filesystem boost_program_options taglib JSON)
set(OS_LIBS pthread sqlite3.a dl)
set(CMAKE_EXE_LINKER_FLAGS "-Wl")
set(PREPROCESSOR_DEFINITIONS ${PREPROCESSOR_DEFINITIONS};/DTAGLIB_STATIC)
endif(LINUX)
When I removed this setting, the build succeeded. This oversight has been around a while, with the earlier version of gcc not minding. The latest gcc, however, is more pedantic and flagged it as an error.