I now work on C code coverage study and encountered following issue, GCC version 4.4.6:
Added compiler flag CFLAGS = --coverage and linker option LDFLAGS := --coverage or LOCAL_LDLIBS := --coverage and got the error:
undefined reference to '__gcov_init'" and "undefined reference to '__gcov_merge_add'
Added option LOCAL_LDFLAGS := --coverage, and got link error:
libgcov.a(_gcov.o): in function __gcov_set_sampling_rate: undefined reference to '__gcov_sampling_rate'
libgcov.a(_gcov.o): in function gcov_exit: undefined reference to '__gcov_pmu_profile_filename'
libgcov.a(_gcov.o): in function __gcov_init: undefined reference to '__gcov_pmu_profile_options' '__gcov_pmu_top_n_address'
Can anyone help to provide some suggestions on this issue?
Try this approach:
Compile the code for which you want to generate the coverage with these options:
CFLAGS: -fprofile-arcs -ftest-coverage
LFLAGS: -lgcov --coverage
If this doesn't solve the problem, then please provide some information on the structure of your application, i.e. whether its single program or an application involving shared/static libraries etc.
Are you linking with -lgcov?
If you are using a Makefile it would be of great help to have a look at it in order to help you.
you have to provide LDFLAGS to resolve this issue.
LDFLAGS += " -lgcov --coverage"
I can't be sure which change finally did the trick for me but I think it was the -fprofile-generate flag. Using GNAT GPS I went to the Switches tab on the left and then selected the Ada Linker tab on the top. Then I enabled the checkbox for Code Coverage. Oh yeah I've found that on the Builder tab in that same area if you enable the Recompile if switches changed checkbox it can save a lot of teeth-gnashing. Probably slows things down for the pros but I found it helpful.
I found I had to put the '-lgcov' to the right of the object being profiled instead of in Flags. Something like.
gcc -pg -o myprog myprog.o -lgmp.a -lgcov
I had undefined reference to gcov functions (undefined reference to '__gcov_exit') while I tried to enable coverage on a C project using a C++ test harness (CppUTest). Build system was handled by CMake.
Compilers and gcov were aligned on the same version (gcc --version, g++ --version and gcov --version gave the same version) but it seems that my build system was previously configured to use gcc 5 while g++ 8 and gcov 8 were used (resulting to an additional included directory by the linker: usr/lib/gcc/x86_64-linux-gnu/5). I cleaned the build tree and generated it again thanks to CMake which fixed the error.
I have seen this issue too and as most of the answers above indicated it needed us to add lcov/gcov libraries at the time of linking.
We are using cmake and in CmakeLists.txt file we were missing
target_link_libraries(${TARGET_NAME} PRIVATE gcov)
This was needed of course in addition to the build flag "--coverage"
(Pls note we can either use "--coverage" or "-fprofile-arcs -ftest-coverage" separately)
Related
I'm trying to compile a simple unit test on my windows machine.
When I'm trying to compile my test I'm using the shared library flag.
gcc -c -L./bin/ -lcmocka .\Test.c .\src\some_module.c
gcc .\Test.o .\some_module.o -o main
But the second line throws this error:
undefined reference to `_cmocka_run_group_tests'
However, if I'm compiling using directly the cmocka.c file which I downloaded from their git it works fine:
gcc -c .\lib\cmocka.c .\Test.c .\src\some_module.c
gcc .\Test.o .\some_module.o .\cmocka.o
What am I doing wrong in the first compilation?
In addition, I would happy to understand the difference between the two compilations. Which one is the better practice?
Thank you
In order to compile your code, the compiler does not need to know where to look for the library. It's enough if the compiler "finds" the declarations of the functions which are usually in the header files provided by the library.
This step is done in the first line of your compilation procedure (maybe you need to specify the folder to the header files by adding -Ipath/to/headers/):
gcc -c .\Test.c .\src\some_module.c
The library itself is "combined" with your code during the linking step, which is done during your second compilation step. Here you need to specify the library (and its path via -Lpath/to/library, if the linker does not find the library on its own):
gcc .\Test.o .\some_module.o -o main -L./bin/ -lcmocka
You should definitely not use your second approach and compile the library by yourself.
Based on This Stackoverflow link I downloaded & installed glibc v2.29 in "/usr/local/glibc" path of Linux OS. Then based on this Stackoverflow link I tried to compile This Example, But I got following errors.
First Try Command:
gcc -Wall -g -o main main.c -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
First Try Error Log:
main.c:1:10: fatal error: threads.h: No such file or directory
#include <threads.h>
^~~~~~~~~~~
compilation terminated.
Second Try Command:
In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
Second Try Error Log:
/tmp/ccCNYemW.o: In function `main':
/home/.../main.c:14: undefined reference to `thrd_create'
/home/.../main.c:16: undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
So I don't know where is the problem. Please Help me.
First of all, don't put an alternate libc (or alternate version of your libc) in a path searched by the normal include and library search (both link-time and runtime library search) for your main system one. This is a recipe for disaster. Installing a different glibc in /usr/local/ does avoid clobbering your system one, but now you just have two installed in places where the same tools can see and use them.
To do this right, you really need a full separate toolchain (gcc, binutils) in some completely separate path (like ~/my_glibc_root/... or /opt/alt_glibc_root/...). I'm not sure if there's a recommended way to do this. The glibc build procedures in Linux From Scratch might be a good place to look for ideas. In theory it can be done in a single stage; I do that with musl libc in musl-cross-make by careful use of intermediate make rules in the gcc build system. But applying the same idea to glibc probably requires some extra care.
Second Try Command: In second try, I am using "-I" & "-L" GCC command options.
gcc -Wall -g -I/usr/local/glibc/include -o main main.c -L/usr/local/glibc/lib -Wl,--rpath=/usr/local/glibc/lib -Wl,--dynamic-linker=/usr/local/glibc/lib/ld-linux-x86-64.so.2
This command is almost correct. The thrd_create and thrd_join functions are defined in libpthread, which you didn't link against.
Add -pthread to your compile command, and the link should succeed.
P.S. R's advice of not installing alternate GLIBC into /usr/local is also a good one.
I'm using cmake to generate a gstreamer library. In the end cmake uses the following command for linking:
/usr/bin/cc -fPIC -shared -Wl,-soname,libmacq-gstmelpi.so -o libmacq-gstmelpi.so <OBJECT_FILES> -lmacq-melpi -lmacq-icar-tools -lmacq-gstmecimeta -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0
Note the -lgstvideo-1.0 flag at the end. The command runs fine, no error is produced, and the resulting library is created just fine. However when I use the library, I get undefined symbol error. So I use ldd to check; and amongst all the output of ldd; libgstvideo-1.0.so is not to be found.
This problem occurs on Ubuntu 14.04 on a armhf architecture. The problem does not occur on opensuse 13.1 (i586) nor on opensuse 13.1 (armv7hl), since in that case ldd libmacq-gstmelpi.so | grep gstvideo gives:
libgstvideo-1.0.so.0 => /usr/lib/libgstvideo-1.0.so.0 (0xb715f000)
EDIT :
I have another library, very similar where a very similar command works just fine; the resulting library is correctly linked to libgstvideo-1.0.so
/usr/bin/cc -fPIC -shared -Wl,-soname,libmacq-gstplugins.so -o libmacq-gstplugins.so <OBJECT_FILES> -lmacq-icar-tools -lmacq-gstmecimeta -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lgstvideo-1.0
Some remarks on what I have checked and tried:
/usr/lib/arm-linux-gnueabihf/libgstvideo-1.0.so exists. (the other libraries in /usr/lib/arm-linux-gnueabihf/ are found without problem, libmacq-gstmelpi.so is linked to /usr/lib/arm-linux-gnueabihf/libgstreamer-1.0.so.0 without problem)
I tried changing the order, and putting the -lgstvideo-1.0 flag before all other -l flags; no succes.
replacing cc with c++ or gcc; the commands work, but output is the same
removing -lgstvideo-1.0 on a system where the build worked. The resulting library builds (links) without error; yet upon execution I have the same undefined symbol error as on Ubuntu. This proves that the missing symbol is in libgstvideo-1.0.so, and that I need it.
Are you actually using symbols from that particular library or do you just want to link to it to avoid linking it in the application that uses the library later on?
It could be a default compiler behavior that it skips linking of libraries when no symbol from these are actually used.
Try -Wl,--no-as-needed to your flags. In this case the library should get linked - not checking whether its symbols are actually used or not.
EDIT:
After chatting it turned out that the actual desired symbols are in gstbase-1.0 and not gstvideo-1.0. Since gstvideo-1.0 pulls in gstbase-1.0 as a dependency this worked but would cause problem as the linker may remove this dependency since no symbols from this particular library are being used. Linking directly to gstbase-1.0 seemed to solve all issues.
I started experimenting with C/C++ the other day because I needed it for reading level-4 MAT-files without needing to purchase the Matlab editor or compiler. So I found just the library that I needed but I'm not familiar with C or C++ at all so I'm a beginner with those two languages. Anyhow I need to include the 'matio' library. I've tried many things but I've had no luck.
I right clicked on the C/C++ project > properties > C/C++ General > Paths & Symbols > GNU C and added the path to the matio library.
I also went to C/C++ Build > Settings > Tool settings > GCC C Compiler > Includes and added the path there aswell.
Since I'm not any good with makefiles yet I did not specify my own makefile, instead I chose a executable project.
When I try to build my project it complains about a function called 'Mat_Open' in the matio library. When I hover over it, it says "undefined reference to 'Mat_Open'" the header 'matio.h' seems to work fine but it can't refer to 'Mat_Open' for some reason.
How do I solve this?
EDIT:
Here is the whole build console output.
10:42:52 **** Incremental Build of configuration Debug for project Project ****
Info: Internal Builder is used for build
gcc -IC:/matio-1.5.2/src -O0 -g3 -Wall -c -fmessage-length=0 -o CComponent.o "..\\CComponent.c"
gcc -Xlinker -lm -o Project.exe CComponent.o -lC:/matio-1.5.2/src
c:/mingw(x64)/bin/../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:/matio-1.5.2/src
collect2.exe: error: ld returned 1 exit status
10:42:53 Build Finished (took 330ms)
This is not necessarily an answer but may be useful for a comparison.
First of all, where did you install it? If your using Linux or Mac OSX you will want to install in the system directories (not sure about Windows). I use OSX so in my makefile (by the way I use Qt):
LIBS += -L/usr/local/lib/ -lmatio
INCLUDEPATH += /usr/local/include
Then of course, in the *.h files of my source I use:
#include "matio.h"
But I assume you have already tried that?
I am creating a utility which depends on libassuan aside other depends. While these ‘others’ provide shared libraries, libassuan comes with static one only.
libassuan comes with simple libassuan-config tool which is meant to provide CFLAGS & LDFLAGS for the compiler/linker to use. These LDFLAGS refer to the library as -lassuan.
The result of standard call of make is then:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -lassuan -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o
mirage-password.o: In function `mirage_input_password':
mirage-password.c:(.text+0x1f): undefined reference to `assuan_pipe_connect'
mirage-password.c:(.text+0x32): undefined reference to `assuan_strerror'
collect2: ld returned 1 exit status
make: *** [mirage2iso] Error 1
(I've just started writing this unit and that's why there aren't more errors)
So, if I understand the result correctly, gcc doesn't want to link the app to libassuan.a.
Using -static here will cause gcc to prefer static libraries over shared which is unindented. I've seen solution suggesting using something like that:
-Wl,-Bstatic -lassuan -Wl,-Bdynamic
but I don't think it would be a portable one.
I think the best solution would be to provide full path to the static library file but libassuan-config doesn't provide much of help (all I can get from it is -L/usr/lib64 -lassuan).
Maybe I should just try to create the static library path by ‘parsing’ returned LDFLAGS and using -L for the directory name and -l for the library name — and then hoping that in all cases libassuan-config will return it like that.
What do you think about that? Is there any good, simple and portable solution to resolve the issue?
PS. Please note that although I'm referring to gcc here, I would like to use something that will work fine with other compilers.
PS2. One additional question: if package does install static library only, returning such LDFLAGS instead of full .la path can be considered as a bug?
gcc will link to libassuan.a if it doesn't find libassuan.so
It's probably the order symbols are looked up in the static library when you link. The order matters.
)
Assuming gcc can find libassuan.a and it actually provides the functions the linker complains about, try:
cc -I/usr/include/libmirage -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -lmirage -lglib-2.0 -L/usr/lib64 -o mirage2iso mirage2iso.c mirage-getopt.o mirage-wrapper.o mirage-password.o -lassuan
Since you say libassuan is under /usr/lib64 it's probably a 64 bit library, are your app and the other libraries 64 bit as well ?
Compiler's command-line options are not a portable thing. There's no standard for it. Every compiler uses its own and several can merely informally agree to comply with each other in command-line format. The most portable way for your linking is to use libassuan-config, of course. I think, it can generate not only flags for gcc, but for other compilers as well. If it can't, then no portable way exists, I suppose (other than CMake or something on higher level).
The command line to cc you shown is totally correct. If you have a static library libassuan.la and path to it is supplied to -L option, then the compiler does link against it. You can see it from its output: has it not found the static library, would it complain with error message like "can't find -lassuan". I
Moreover, if no libassuan.so is found, then compiler links against your library statically, even if you haven't used -Wl,-Bstatic stuff or -static flag.
Your problem may be in persistence of several versions of libassuan in your system. Other that that, I don't see any errors in what you've provided.
Which directory is libassuan.a in
I think the first error is not gcc doesn't want to link the app to libassuan.a it is more gcc does not know where libassuan.a . You need to pass gcc a -L parameter giving the path to libassuan.a .
e.g.
-L /home/path