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

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
hexdump -e '"%x\n"' -s8 -n4 fe-lobj.gcno

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* 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

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!
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to