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)
