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
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
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:
mismatch with notes file
geninfo: WARNING: gcov did not create any files for
gcov -b -f -p -o . fe-lobj.c >fe-lobj.c.gcov.out
./fe-lobj.gcda:stamp mismatch with notes file
First hit 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
hexdump -e '"%x\n"' -s8 -n4 fe-lobj.gcno
Second hit 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
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
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.
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 (firstname.lastname@example.org)
To make changes to your subscription: