On 2026-Oct-03, Tom Lane wrote:
> Testing this locally, it initially didn't seem to be doing anything.
> But that turns out to be because Red Hat has stuck with lcov 2.0-1,
> which does not produce the "duplicate file" error. What it does do
> is blindly read every foo.gcda file twice, resulting in counts twice
> what they should be :-(. Now I wonder whether pre-2.0 lcov did the
> same ... but I don't have an old executable laying about to test with.
>
> I gather that coverage.postgresql.org is running a VPATH build,
> because it shows some odd coverage counts as well as even ones.
> That's impossible in an in-tree build with this bug, if I've
> diagnosed it correctly.
Hmm, no, it's running an in-tree build,
./configure --cache-file=/home/coverage/pgsrc/configure.cache --enable-depend --enable-coverage --enable-tap-tests
--enable-nls--with-python --with-perl --with-tcl --with-openssl --with-libxml --with-ldap --with-pam --with-llvm
--with-lz4--enable-injection-points CFLAGS=-O0 'CPPFLAGS=-DCOPY_PARSE_PLAN_TREES -DWRITE_READ_PARSE_PLAN_TREES
-DRAW_EXPRESSION_COVERAGE_TEST'LLVM_CONFIG=/usr/bin/llvm-config-19 CLANG=clang-19 >> $LOG 2>&1
So, I was going to say that Debian packages the same version:
coverage@galvin:~$ lcov --version
lcov: LCOV version 2.0-1
but I found out that the packaging files have a patch file that modifies
the version string, so the code that's actually running is 2.3, not 2.0.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142382
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La espina, desde que nace, ya pincha" (Proverbio africano)
