tl;dr: It's critical that you actually do a make install, or at least it
is if you've set --prefix with configure. If you don't, then even if you
do make check you'le going to get the *installed* libpq, and not the
*built* libpq.
Also, looks like there's a race between the .info and .c.gcov targets
with parallel make; I'm wondering if there's a way to fix that by not
allowing parallelism in each directory...? (Presumably the issue is the
rm *.gcov). It'd be nice to fix this because -j speeds up coverage-html
a lot, even with just 2 cores.
On 10/27/16 9:38 PM, Peter Eisentraut wrote:
On 10/27/16 1:27 PM, Jim Nasby wrote:
Well, that got me closer, but it's still blowing up on libpq:
genhtml: ERROR: no valid records found in tracefile
./src/interfaces/libpq/lcov.info
I have seen similar problems when I use a gcov that does not match the gcc.
I switched back to macports gcc6, verified version correctness, and got
further (though still broken). Looking through the build log:
Processing fe-lobj.gcda
/Users/decibel/pgsql/HEAD/src/interfaces/libpq/fe-lobj.gcda:stamp
mismatch with notes file
geninfo: WARNING: gcov did not create any files for
/Users/decibel/pgsql/HEAD/src/interfaces/libpq/fe-lobj.gcda!
...
gcov -b -f -p -o . fe-lobj.c >fe-lobj.c.gcov.out
./fe-lobj.gcda:stamp mismatch with notes file
First hit[1] on "google:gcov mismatch with notes file" led me to this
hexdump command (picking a libpq file at random...)
hexdump -e '"%x\n"' -s8 -n4 fe-lobj.gcda
6929786
hexdump -e '"%x\n"' -s8 -n4 fe-lobj.gcno
d93a160
Second hit[2] gives a better explaination: the files were rebuilt a
second time. While I don't see that happening in the log, his example is
from building a shared library, so I'm wondering if that's got something
to do with this.
I went into src/interfaces/libpq, did rm *.gc* lcov.info. After doing
that, a second run of make coverage-html worked fine.
I'm wondering if there's some magic involved in coverage with shared
libraries...
Actually, after a bunch of other experiments I ran those hexdump
commands again; the value for .gcno has changed, but the value for .gcda
hasn't. So I'm wondering if the base system libpq is getting pulled in.
Sure enough, if I also do make install the timestamp matches. Presumably
this is all due to having set --prefix with configure.
I was able to run it successfully using CC=gcc-6 and GCOV=gcov-6 from
Homebrew.
I tried that as well; it didn't work either. I didn't run a diff, but it
appeared to be doing the same thing that macports gcc6 was.
1:
http://stackoverflow.com/questions/27276155/gcov-generates-empty-coverage-for-c
2: http://stackoverflow.com/a/26061575/4196282
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
