Failing to get gcov coverage file with my C/C++ Makefile project with googletest on Windows with mingw32
Full source code at https://github.com/rusefi/rusefi/tree/gcov/unit_tests
I have
USE_OPT += -fprofile-arcs -ftest-coverage
ULIBS += -lgcov --coverage```
and I get .gcno files next to my .o files in build\obj folder
I execute rusefi_test.exe and I see no new files with coverage data :(
nm rusefi_test.exe
confirms that gcov is inside my binary
I've already added explicit flush at the end
extern "C" void __gcov_flush();
__gcov_flush();
but I still do not see any
90.00% of 10 source lines executed in file tmp.c
style line at the end of stdout
I've tried copying my .exe from build to build\obj folder but this did not improve anything.
It looks like my compiler has something to do with this! I've moved to a simple HelloWorld.cpp application and depending on compiler I either get runtime file or not!
main.exe produced by "g++" from cygwin produces the runtime file while x86_64-w64-mingw32-g++ from cygwin does NOT produce main.gcda file!
x86_64-w64-mingw32-g++ bundled with cygwin seems to be affected while same x86_64-w64-mingw32-g++ downloaded directly from mingw64 seems to work.
There is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854368 which they say is closed but at least tells me that sometimes it's about the compiler itself :(
Related
I'm adding code coverage on a C project of mine. The process I'm following is this:
# compile a .c file, expecting two new files "a.out" and "main.gcno"
gcc --coverage main.c
# run executable to get coverage data, expecting to create a new "main.gcda" file
./a.out
# use `gcov` to get formatted reports
gcov main.c
When I'm using gcc on version 10.3.0, this all works as expected without issues. When using gcc with version 11.1.0 however, both the main.gcno and main.gcda files have a different name, which breaks the flow as explained below.
Using gcc --coverage main.c produces two files, a.out and a-main.gcno. Then running the executable with ./a.out creates a new file a-main.gcda. Notice the prefix a- on the coverage files. When running the next command gcov main.c, I get the following error:
main.gcno:cannot open notes file
main.gcda:cannot open data file, assuming not executed
Because it is looking for the files main.gcno and main.gcda, but it can't find them.
Why does the new version of gcc do that? Everything I read online assumes that the output of the compiler should be in sync with gcov when run on the same source file. I couldn't find anywhere a way to change the output name of coverage files.
In case it helps, I also noticed the a- prefix depends on the output name. So if an output name is specified (gcc --coverage main.c -o test) then the coverage files will have that as prefix (test-main.gcno and test-main.gcda).
I've also tried manually renaming the files to remove the prefix, and gcov seems happy with that. The problem is that I'm trying to automate the process, and I'd like a more robust way than trying to guess what output name the compiler uses for coverage files.
For reference, I'm also using gcov on version 11.1.0. It's not clear to me if that's related to the gcc being the same version.
Why does the new version of gcc do that?
See the release notes for GCC 11, specifically the third bullet of the Caveats which starts "Naming and location of auxiliary and dump output files changed".
Everything I read online assumes that the output of the compiler should be in sync with gcov when run on the same source file. I couldn't find anywhere a way to change the output name of coverage files.
As it says in the release notes, the -dumpbase option is what you want. To remove any prefix, use -dumpbase ''
I'm not sure whether gcov should have been updated, or if the gcc-11 change should not have affected the coverage files. Edit: This is behaving as expected.
Another solution is to compile and link in two separate steps:
gcc --coverage main.c -c
gcc --coverage main.o
This way the coverage data files do not get the prefix, and gcov finds them as expected.
I have a c file inside "examples" folder inside ArtoolKIt that I want to compile in Ubuntu.
Artoolkit works perfectly, but how can I compile this c file from terminal?
I try ./helloWorld but it gives me this error:
No such file or directory
Is there any specific way to compile Artoolkit programs cause I don't see it in its docuemntation.
Use either gcc or clang to compile .c files:
gcc -o hello ./examples/filename.c
the parameter following the -o flag names the file that will be produced by the operation, a parameter without any flag named the source input file.
So, the problem that I had was with my directories! For this wo work you should have inside teh folder Examples of ArtoolKit the thiungs: a folder with data, your c file to be compiled and teh makefile in case you have it so youy can compile with $make command.
Now It works for me!
My Ubuntu version is 14.04 LTS. I have a C program copied on the desktop by the name sendRawEth.c. When I write:
gcc sendRawEth.c -o sendRawEth
The compiler complains:
gcc: error: sendRawEth.c: No such file or directory
gcc: fatal error: no input files
I have no idea how to solve this error.
please do the following.
On terminal check the present directory by 'pwd' command and then check the directory in which your programme is there and see if they are same or not. And while writing gcc yourfile it's case sensitive. Hope this helps
There are 2 reasons for such errors.
You said you copied your C programs in your desktop folder.
This means you may have only copied sendRawEth.c. file format not the executable file.
You should ensure you copy the .exe files as well.
You need to change the directory to the same folder that you copied your programs into.
First, check your current folder by typing pwd.
Then change it to your required folder with:
cd /outerfolder/your program folder
Then compile it with:
gcc -o programname programname.c
And finally execute it with:
./programname
I'm attempting to use a C library for an opencourseware course from Harvard. The instructor's instructions for setting up the external lib can be found here.
I am following the instructions specific to ubuntu as I am trying to use this lib on my ubuntu box. I followed the instructions on the page to set it up, but when I run a simple helloWorld.c program using a cs50 library function, gcc doesn't want to play along.
Example:
helloWorld.c
#include <stdio.h>
#include <cs50.h>
int
main(void){
printf("What do you want to say to the world?\n");
string message = GetString();
printf("%s!\n\n", message);
}
$ gcc helloWorld.c
/tmp/ccYilBgA.o: In function `main':
helloWorld.c:(.text+0x16): undefined reference to `GetString'
collect2: ld returned 1 exit status
I followed the instructions to the letter as stated in the instructions, but they didn't work for me. I'm runing ubuntu 12.04. Please let me know if I can clarify further my problem.
First, as a beginner, you should always ask GCC to compile with all warnings and debugging information enabled, i.e. gcc -Wall -g. But at some time read How to invoke gcc. Use a good source code editor (such as GNU emacs or vim or gedit, etc...) to edit your C source code, but be able to compile your program on the command line (so don't always use a sophisticated IDE hiding important compilation details from you).
Then you are probably missing some Harvard specific library, some options like -L followed by a library directory, then -l glued to the library name. So you might need gcc -Wall -g -lcs50 (replace cs50 by the appropriate name) and you might need some -Lsome-dir
Notice that the order of program arguments to gcc is significant. As a general rule, if a depends upon b you should put a before b; more specifically I suggest
Start with the gcc program name; add the C standard level eg -std=c99 if wanted
Put compiler warning, debugging (or optimizing) options, eg -Wall -g (you may even want to add -Wextra to get even more warnings).
Put the preprocessor's defines and include directory e.g. -DONE=1 and -Imy-include-dir/
Put your C source file hello.c
Put any object files with which you are linking i.e. bar.o
Put the library directories -Lmy-lib-dir/ if relevant
Pur the library names -laa and -lbb (when the libaa.so depends upon libbb.so, in that order)
End with -o your-program-name to give the name of the produced binary. Don't use the default name a.out
Directory giving options -I (for preprocessor includes) and -L for libraries can be given several times, order is significant (search order).
Very quickly you'll want to use build automation tools like GNU make (perhaps with the help of remake on Linux)
Learn also to use the debugger gdb.
Get the habit to always ask for warnings from the compiler, and always improve your program till you get no warnings: the compiler is your friend, it is helping you!
Read also How to debug small programs and the famous SICP (which teaches very important concepts; you might want to use guile on Linux while reading it, see http://norvig.com/21-days.html for more). Be also aware of tools like valgrind
Have fun.
I take this course and sometimes I need to practice offline while I am traveling or commuting. Under Windows using MinGW and Notepad++ as an IDE (because I love it and use it usually while codding python) I finally found a solution and some time to write it down.
Starting from scratch. Steps for setting up gcc C compiler, if already set please skip to 5
Download Git and install. It includes Git Bash, which is MINGW64 linux terminal. I prefer to use Git as I need linux tools such as sed, awk, pull, push on my Windows and can replace Guthub's terminal.
Once Git installed make sure that gcc packages are installed. You can use my configuration for reference...
Make sure your compiler works. Throw it this simple code,
by saving it in your working directory Documents/Harvard_CS50/Week2/
hello.c
#include <stdio.h>
int main(void)
{
printf("Hello StackOverflow\n");
}
start Git Bash -> navigate to working directory
cd Documents/Harvard_CS50/Week2/
compile it in bash terminal
gcc helloworld.c -o helloworld.exe
execute it using bash terminal
./helloworld.exe
Hello StackOverflow
If you see Hello StackOverflow, your compiler works and you can write C code.
Now to the important bit, installing CS50 library locally and using it offline. This should be applicable for any other libraries introduced later in the course.
Download latest source code file cs50.c and header file cs50.h from https://github.com/cs50/libcs50/tree/develop/src and save them in Documents/Harvard_CS50/src
Navigate into src directory and list the files to make sure you are on the right location using
ls
cs50.c cs50.h
Cool, we are here. Now we need to compile object file for the library using
gcc -c -ggdb -std=c99 cs50.c -o cs50.o
Now using the generated cs50.o object file we can create our cs50 library archive file.
ar rcs libcs50.a cs50.o
After all this steps we ended with 2 additional files to our original files. We are interested in only 2 of them cs50.h libcs50.a
ls
cs50.c cs50.h cs50.o libcs50.a
Copy Library and header files to their target locations. My MinGW is installed in C:\ so I copy them there
cs50.h --> C:\MinGW\include
libcs50.a --> C:\MinGW\lib
Testing the cs50 Library
To make sure our library works, we can throw one of the example scripts in the lecture and see if we can compile it using cs50.h header file for the get_string() method.
#include <stdio.h>
#include <cs50.h>
int main(void)
{
printf("Please input a string to count how long it is: ");
string s = get_string();
int n = 0;
while (s[n] != '\0')
{
n++;
}
printf("Your string is %i chars long\n", n);
}
Compile cs50 code using gcc and cs50 library. I want to be explicit and use:
gcc -ggdb -std=c99 -Wall -Werror test.c -lcs50 -o test.exe
But you can simply point the source, output filename and cs50 library
gcc test.c -o test.exe -lcs50
Here we go, program is compiled using header and methods can be used within.
If you want Notepad++ as an IDE you can follow this tip to set it up with gcc as a compiler and run your code from there.
Just make sure your nppexec script includes the cs50 library
npp_save
gcc -ggdb -std=c99 -Wall -Werror "$(FULL_CURRENT_PATH)" -lcs50 -o "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
cmd /c "$(CURRENT_DIRECTORY)\$(NAME_PART).exe"
Download the cs50 from: http://mirror.cs50.net/library50/c/library50-c-5.zip
Extract it. (You will get two files cs50.c and cs50.h)
Now copy both the files to your default library folder. (which includes your stdio.h file)
Now while writing your program use: #include < cs50.c >
You can also copy the files to the folder containing your helloWorld.c file.
You have to use: #include " cs50.c ".
OR =====================================================================>
Open cs50.c and cs50.h files in text editor.
In cs50.h, just below #include < stdlib.h > add #include < stdio.h > and #include < string.h > both on new line.
Now open cs50.c file, copy everything (from: /**Reads a line of text from standard input and returns the equivalent {from line 47 to last}) and paste it in cs50.h just above the #endif and save the files.
Now you can copy the file cs50.h to either your default library folder or to your current working folder.
If you copied the file to default folder then use: #include < cs50.h > and if you copied the files to current working folder then use: #include " cs50.h ".
You need to link against the library during compilation. The library should end in .a or .so if you are on Ubuntu. To link against a library:
gcc -o myProgram myProgram.c -l(library name goes here but no parentheses)
You have to link against the library, how come GCC would know what library you want to use?
gcc helloWorld.c -lcs50
Research Sources:
building on the answers above given by Basile Starynkevitch, and Gunay Anach
combined with instructions from some videos on youtube 1 2
Approach:
covering the minimum things to do, and sharing the "norms" separately
avoiding any modification to anywhere else on the system
including the basic breakdown of the commands used
not including all the fine details, covering only the requirements absolute to task or for effective communication of instructions. leaving the other mundane details to the reader
assuming that the other stuff like compiler, environment variable etc is already setup, and familiarity with shell's file navigation commands is there
My Environment:
compiler: gcc via msys2
shell: bash via msys2
IDE: doesnt matter here
Plan:
getting the source files
building the required files: *.o (object) and *.a (archive)
telling the compiler to use it
Action:
Let's say, current directory = "desktop/cs50"
It contains all the *.c files like test-file.c which I will be creating for assignments/problem sets/practise etc.
Get the *.h and *.c files
Source in this particular case: https://github.com/cs50/libcs50/tree/main/src
Go over each file individually
Copy all the content of it
Say using "Copy raw contents" icon of individual files
Create the corresponding file locally in the computer
Do it in a a separate folder just to keep things clean, let's say in "desktop/cs50/src" aka ./src
Build the required files using in the terminal after changing your current directory to "desktop/cs50/src" :
gcc -c cs50.c to create the "cs50.o" object file from "cs50.c" using "gcc"
ar cr libcs50.a cs50.o to create "libcs50.a" archive file which'll be containing "cs50.o" object file
Here, "libcs50" = "lib" prefix + "cs50" name (same as the header file's name)
This is the norm/standard way where the prefix "lib" is significant as well for a later step
However, prefix can be skipped, and it's not compulsory for name to match the header file's name either. Though, Skipping prefix is not recommended. And I can't say for sure about the name part
To tell the compiler to be able to use this infrastructure, the commands will be in following syntax after going to the parent directory (i.e. to "desktop/cs50"):
gcc test-file.c -Isrc -Lsrc -lcs50 if you used "lib" prefix in step 2.2 above
here, -I flag is for specifying the directory of *.h header file included in your test_file.c
and -L flag is for specifying the directory to be used for -l
and -l is for the name of the *.a file. Here the "lib" prefix talked about earlier, and ".a" extension is not mentioned
the order of these flags matter, keep the -I -L -l flags after the "test-file.c"
Some more notees:
don't forget to use the additional common flags (like those suggested above for errors etc)
if you skipped the "lib" prefix, then you can't use -L -l flags
so, syntax for command will become: gcc test-file.c -Isrc src/libcs50.a
say i created my test-file.c file in "desktop/cs50/psets", so, it can be handled in 2 notable ways (current dir = "desktop/cs50/") :
cd psets then changing the relative address correspondingly in -I -L, so result:
gcc test-file.c -I../src -L../src -lcs50
keeping current directory same, but then changing the file's relative address correspondingly, so result:
gcc psests/test-file.c -Isrc -Lsrc -lcs50
or use absolute addresses 😜
as it can be seen that this becomes quite long, that's when build automation tools such as make kick in (though i am accomplishing that using a shell script 😜)
MPICH2 is installed in C:\Program Files\MPICH2. There are two subdirectories (of interest), \include which contains .h files, and \lib which contains .lib files.
The readme that comes with MPICH2 has the following instructions:
create a makefile
add –I...mpich2\include
add –L...mpich2\lib
add –lmpi
add the rules for your source files
compile
Since there are no other rules in my project, I don't create a makefile, I just go to the command line and try compiling like this:
g++ -I"C:\Program Files\MPICH2\include" main.cpp -L"C:\Program Files\MPICH2\lib" -lmpi
This gives me a fistful of undefined reference errors on every single MPI symbol in the code. I spent hours trying to fix it, juggling -I, -L and -l switches around, shuffling the order of the parameters, even copied all the .lib files into the same directory as my source, but nothing seems to work.
What kind of voodoo is needed to get this thing to link?
EDIT: I think I found the problem: here's an excerpt of the linker's output in verbose mode (adding -Wl,--verbose to the compile command):
attempt to open C:\Program Files\MPICH2\lib/libmingwex.dll.a failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.dll.a failed
attempt to open C:\Program Files\MPICH2\lib/libmingwex.a failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.lib failed
attempt to open C:\Program Files\MPICH2\lib/libmingwex.dll failed
attempt to open C:\Program Files\MPICH2\lib/mingwex.dll failed
attempt to open C:\Program Files\MPICH2\lib\libmingwex.a failed
Apparently, the linker adds a / instead of a \ to the directory names I supply it with (except when looking for the lib___.a format for some reason), which is obviously not a valid path. Is there any way to tell the linker to use backslashes instead of slashes?
This also caught my eye:
attempt to open /mingw/lib/libmingwex.a succeeded
So I tried compiling like this:
g++ -I"/Program Files/MPICH2/include" -L"/Program Files/MPICH2/lib" objManager.cpp ongom.cpp io.cpp main.cpp -lmpi -lcxx
But I still get the same undefined reference errors.
GCC is able to find your library. Otherwise it would report: cannot find -lmpi.
Somehow it happens that the routines cannot be found in that library. I managed to compile an example with this syntax:
g++ -I../include cpilog.c ../lib/mpi.lib ../lib/mpe.lib
I did that inside msys though. And my directory does not contain spaces.
After removing libmpi.a file, this also works:
g++ -I../include -L../lib cpilog.c -lmpi -lmpe
try adding -lmpicxx (the lib for the c++ bindings), and make sure the -l... come after the cpp source file *. this works for me:
g++ -Iinclude -Llib test/cxxpi.cpp -lmpicxx -lmpi
EDIT: re: "undefined reference to 'MPI_Comm_rank'": could it be that your are mixing up / using c and / instead of c++? MPI_Comm_rank seems to be the c binding - the c++ binding would be MPI::Comm::Get_rank(). maybe try compiling your program as c, or, if you want to use c++, using the proper bindings (see cxxpi.cpp in the examples dir)?
* http://newsgroups.derkeiler.com/Archive/Comp/comp.parallel.mpi/2006-08/msg00036.html
I had the similar problem resulting from linking 32-bit object files with 64-bit MPICH library. Linking with 32-bit libmpi.a solved the problem.
I had a similar issue with mingw: for those library files with a .lib ending, I had to put the name of the library without the ending (e.g. -llibboost_system-mgw34-mt when the filename is libbboost_system-mgw34-mt.lib). For library files with a .a ending, I had to put the name of the library excluding the starting "lib" and the trailing .a (e.g. -lws2_32 for libws2_32.a).
So in your case - try -llibmpi (or whatever your file is called without the .lib ending), perhaps it's the same issue.
from: http://www.mingw.org/node/98/revisions/358/view
Note: some paths were printed with “/” as the path separator while some other was printed with “\” as the path separator. I've substitued all with “/” as MinGW GCC accept both.
So I would not put too much time into finding a way to correct the path seperator. Is your library compiled for mingw?
perhaps: http://www.mingw.org/wiki/LibraryPathHOWTO helps you a bit further.