For a given sample program I want to know which part of GCC's source code is used during compilation.
BUILDING GCC:
I tried building gcc-8.2 source code using
./src/configure --enable-languages=c,c++
--disable-bootstrap --disable-multilib BOOT_CFLAGS="-O2 -g -ftest-coverage -fprofile-arcs"
I have a sample program named program.c
I am compiling the program.c with xgcc as
/path/to/xgcc -B path/to/stage1build/gcc -ftest-coverage program.c
The above command gives me code coverage of program .The problem is I don't want to find code coverage of program.c using gcov and lcov.
I want to find code coverage of gcc's source code.
I tried searching on web but almost all of the answers tell me how do I use gcov and lcov by giving example of a sample .c program .
NOTE:
I know how to use gcov and lcov
As per searching online for the BOOT_CFLAGS, it seems it sets the default compiler flags for the code that you would be compiling.
Refer here:1, 2
Probably you need to run configure something like this:
./src/configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib CFLAGS="-O2 -g -ftest-coverage -fprofile-arcs" CXXFLAGS="-O2 -g -ftest-coverage -fprofile-arcs"
But you might face other issues while building with coverage enabled GCC Build with coverage.
Better would be to post on GCC mailing list to see if someone has a probable solution.
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.
I am working on a free software application targeted at meteorologists and climate scientists called PIO: https://github.com/NCAR/ParallelIO.
As implied by the name it is a parallel I/O library using MPI.
I am trying to turn on profiling for the accompanying MPE library. There are lots of different documents on line that all mention the option -mpilog, but it's not clear where it should be used, or if something else should be used.
When I try adding -mpilog to either CC, CFLAGS, or LDFLAGS, configure fails with the message that the C compiler does not work.
So how do I turn on logging with MPE? I am using MPICH 3.2 on a Linux system.
I have gotten this working, and here's how.
Firstly, thanks to Gilles Gouaillardet for pointing me at the MPE github site. There is a lot of old information out there about MPE, and it has changed a lot over the years, so reading about it on the GitHub site cleared up a lot of confusion.
For my PIO project, not only did I have to build PIO with MPE, but also HDF5, netcdf-c, and pnetcdf.
HDF5 was built like this:
CC='gcc' CPPFLAGS='-I/usr/local/zlib-1.2.11/include' LDFLAGS='-L/usr/local/zlib-1.2.11/lib' LIBS='-llmpe -lmpe -lmpi -lpthread' ./configure --prefix=/usr/local/hdf5-1.10.5_mpe_static --disable-shared --enable-parallel
netCDF was built like this:
CC='gcc' CPPFLAGS='-I/usr/local/zlib-1.2.11/include -I/usr/local/hdf5-1.10.5_mpe_static/include' LDFLAGS='-L/usr/local/zlib-1.2.11/lib -L/usr/local/hdf5-1.10.5_mpe_static/lib' ./configure --prefix=/usr/local/netcdf-c-4.7.0_hdf5-1.10.5_mpe_static_nodap --disable-shared --disable-dap
pnetcdf was built like this:
CC=gcc LIBS='-llmpe -lmpe -lmpi -lpthread' ./configure --prefix=/usr/local/pnetcdf-1.11.0_mpe --disable-shared --disable-cxx --disable-fortran
The PIO is built like this:
autoreconf -i && CC='gcc' CPPFLAGS='-I/usr/local/pnetcdf-1.11.0_mpe/include -I/usr/local/zlib-1.2.11/include -I/usr/local/hdf5-1.10.5_mpe_static/include -I/usr/local/netcdf-c-4.7.0_hdf5-1.10.5_mpe_static_nodap/include' LDFLAGS='-L/usr/local/pnetcdf-1.11.0_mpe/lib -L/usr/local/zlib-1.2.11/lib -L/usr/local/hdf5-1.10.5_mpe_static/lib -L/usr/local/netcdf-c-4.7.0_hdf5-1.10.5_mpe_static_nodap/lib' LIBS=' -lhdf5_hl -lhdf5 -lz -ldl -lm -llmpe -lmpe -lmpi -lpthread' ./configure --disable-shared --enable-mpe
Note that all the mpicc/mpecc compiler wrappers seemed unable to yield the correct results for this build, because the libraries would be listed in an incorrect order. Only by using CC=gcc, and explicitly linking to -llmpe -lmpe -lmpi -lpthread can this be made to build.
Once built, it gives very nice charts:
My C compiler was working a second ago and making executables, but I started working on a new .c file and suddenly it won't work anymore. I haven't changed anything and I'm still using the same commands, Gitbash version, etc. The compiler is still able to catch errors, so gcc works, but after calling:
gcc -std=c99 my_file.c
there is no executable called my_file.exe. Help sites online suggest installing additional software to fix the error, but I'm hesitant to do so because everything was working fine earlier and I don't want to aggravate the problem with additional software.
Since you have not specified the name of the file to output, GCC will output a.exe.
If you desire output named something else, you must use the -o flag, for example:
gcc -std=c99 -o my_file.exe my_file.c
On Unix, that compiler command would generate an executable a.out. You may find that there is an executable with a default name — but I don't have Windows to check what that name is. Guesses might include a.exe, a_out.exe, aout.exe, etc.
To get my_file.exe:
gcc -std=c99 -o my_file.exe my_file.c
If you don't specify an output -o flag you will get a.exe by default (a.out on other platforms),
gcc -std=c99 my_file.c
If it is working, produces
a.exe
I think you wanted
gcc -std=c99 -o my_file.exe my_file.c
Is there a way for compile a file in llvm (*.ll) that uses functions in C?
I created a test using check C and I compile it as:
$clang counter_i.c counter_test_check.c -lcheck
This way, I am using the libraries from check, but I need produce the llvm code that uses the library from check. When I try this command:
$clang -S -emit-llvm counter_i.c counter_test_check.c
and try execute the code:
$lli-mp-3.5 counter_test_check.ll
I receive this answer:
LLVM ERROR: Program used external function 'srunner_create' which could not be resolved!
I think that a solution is do something as:
$clang -S -emit-llvm counter_i.c counter_test_check.c -lcheck
But it is not supported.
I am thinking that a similar answer is available at:LLVM JIT-compiled program cannot find external functions
Yes, LLVM has a C interface (although there may be some limitations compared to the C++ API):
http://llvm.org/docs/doxygen/html/group__LLVMC.html
I found a solution with:
clang -S -emit-llvm -c counter_test_check.c counter_i.c
clang -o executable counter_test_check.ll counter_i.ll -lcheck
./executable
It does the compilation in two steps and this way I can use other llvm source file.
I want to compile an application with debug information using gcc and gdb. When I do the following, the debug (.dSYM) files are generated correctly:
gcc -ggdb src/test.c -o build/test
If I, however, split this into a compile step and a link step, like this:
gcc -ggdb -c src/test.c -o build/test.o
gcc -ggdb build/test.o -o dist/bin/test
… no .dSYM files are generated at all, and therefore gdb does not show me the source line of code where a crash occurs, which makes debugging a lot more difficult. Since I have quite a bit of source files, compiling and linking them all in a single gcc invocation is not possible.
How can I let gcc generate the .dSYM files when using separate compile and link steps?
Check the second comment on the first answer in this post.
Its a quirk. Maybe you can run the "dsymutil" program manually to generate dSYM files.
You can also specify -g3 in you compilation options so that gcc puts debug symbols right into the binary, not in a separate file. Not sure if that is what you need.