Libtool prefix objects, but gcov requires them without a prefix

Question

I need to do some validation with gcov in the shared library I'm working on.

Problem libtool renames object files from my-name.c to libmylib_la-my-name.lo and gcov cannot handle this conversion. Every time I run it, a cannot open notes file error is generated.

If I manually rename my-name.c to libmylib_la-my-name.c after the gcov build works fine, then there is no other problem associated with changing the file name.

Adding

Trying to provide a minimal working example, I found that a file name crashes only when lib..._la_CFLAGS installed (and also when it is set to empty).

 cat <<EOT > configure.ac AC_INIT(sample,0.0.1) AC_CONFIG_SRCDIR(configure.ac) AM_INIT_AUTOMAKE(foreign) LT_INIT AC_PROG_CC AC_CONFIG_FILES(Makefile) AC_OUTPUT EOT cat <<EOT > Makefile.am lib_LTLIBRARIES=libsample.la libsample_la_SOURCES=sample.c # The following line triggers the filename mangling (libsample_la-sample.lo instead of sample.lo) libsample_la_CFLAGS= EOT touch sample.c && autoreconf -if && ./configure && make 

Is there a way to avoid the manipulation of files managed by libtool, or to let gcov understand the file name change scheme?

Answer 1

Gcov files gcda and gcno are called object files. You can run gcov from the source directory directly in the object file or use the -o gcov option to specify the object file and the corresponding gcov files.

For example, I have a small project that creates a shared library. I pass the gcov flags to execute the command:

 make CFLAGS="-O0 --coverage" LDFLAGS=--coverage 

Object files and corresponding gcno files are created in the src/.libs :

 $ ls -la src/.libs libtest_la-test.o libtest_la-test.gcno 

The source file is in the src folder

 $ ls src/ test.c 

Next, I run my test suite and gcda files are created:

 $ ls -la src/.libs libtest_la-test.o libtest_la-test.gcno libtest_la-test.gcda 

Now I can enter the src directory and run gcov , specifying the file name of the object:

 $ gcov -o .libs/libtest_la-test.o test.c File 'test.c' Lines executed:27.08% of 96 Creating 'test.c.gcov' 

You can also simply run gcov in the object file:

 $ gcov .libs/libtest_la-test.o File 'test.c' Lines executed:27.08% of 96 Creating 'test.c.gcov' 

Or even just specify the base name of the object file and gcov files:

 $ gcov .libs/libtest_la-test File 'test.c' Lines executed:27.08% of 96 Creating 'test.c.gcov' 

But I would suggest another automatic approach that works very well for me using lcov . I call it from the top directory, specifying the paths to the source files and object files:

 $ lcov --base-directory src --directory src/.libs/ --capture --output-file gcov.info Capturing coverage data from src/.libs/ Found gcov version: 4.8.2 Scanning src/.libs/ for .gcda files ... Found 10 data files in src/.libs/ Processing .libs/test_la-test.gcda […] Finished .info-file creation $ genhtml -o html/coverage gcov.info Reading data file gcov.info Found 10 entries. Found common filename prefix "/usr/src/libtest" Writing .css and .png files. Generating output. Processing file src/test.c […] Writing directory view page. Overall coverage rate: lines......: 56.1% (2098 of 3737 lines) functions..: 68.8% (139 of 202 functions) 

The html/coverage directory now contains html files that can be easily parsed in a web browser.

Answer 2

Libtool must not change .c file names. However, it changes the names of the .o files; this is because he needs to compile libraries on some platforms twice (once to create position-independent code (PIC) for .so (shared) libraries, once to create code that is not PIC for .a (static) libraries).

What you can see is that gcov has problems with shared libraries. See “ can gcov deal with shared objects? ” For details.

If this is not fixed, I must agree with Brett that you need more information.