'make check' fails when building with gcov code coverage

[Maarten Hoes]

Hi Miklos,


I totally agree that ideally, if the 'right' way to set these flags for
this build system is setting 'gb_GCOV=YES' on the make commandline, then
this should be fixed. However, I have no knowledge of this particular build
system or makefiles in general, so I am unable to fix that myself. So
instead, I tried setting these *FLAGS on the autogen.sh line, which also
made it work. So it is not so much my preferred way of doing things; merely
a result of my understanding / lack of understanding of certain areas of
expertise.

As for checking if skia gets built with gcc instead of skipped when clang
is not available, what would be the best way to verify that ? I guess that
after the build a 'libskia.so' or something should be present ? I have a
'./instdir/program/libskialo.so', after a gcov build, would that be it ?

By the way, there is a script that assists/attempts to automate doing a
gcov code coverage report (full build / make check) [1] (which I wrote, by
the way, back in 2015 or something), but looking at it now it is not all
that user friendly and/or overengineered. Usage consists of running the
script in different 'steps', and then running 'make check' in between. I
*think* I did it that way in order to make it as flexible as possible,
which seems silly now as it will only get run for the LibreOffice codebase
anyway. The idea was that once I got code coverage for a full build working
again 'in principle', that I take another look at that script and make it
do all the steps in one go, and then see if there is enough interest to run
that automatically on a regular basis somewhere.


[1]
https://git.libreoffice.org/buildbot/+/refs/heads/master/lcov-report/


- Maarten


On Tue, May 31, 2022 at 8:52 AM Miklos Vajna <vmiklos at collabora.com> wrote:

> Hi Maarten,
>
> On Fri, May 27, 2022 at 10:26:21AM +0200, Maarten Hoes <
> hoes.maarten at gmail.com> wrote:
> > CFLAGS='-fprofile-arcs -ftest-coverage' CXXFLAGS='-fprofile-arcs
> > -ftest-coverage' LDFLAGS='-fprofile-arcs -lgcov' ./autogen.sh
> > --enable-python=internal --without-system-libs --without-system-headers
> > gb_GCOV=YES verbose=t make --output-sync=target
> > gb_GCOV=YES verbose=t make check -k --output-sync=target
>
> I believe that manually specifying CFLAGS/CXXFLAGS/LDFLAGS is not
> necessary for coverage, and if you run into problems, we should rather
> fix that.
>
> > I recently started a thread [1] that is about the (complete, not partial)
> > build with gcov failing for me if I only set 'gb_GCOV=YES' on the make
> > commandline. The build succeeds for me if I also set the required *FLAGS
> on
> > the autogen commandline. The failing parts when only using 'gb_GCOV=YES'
> > were/are 'liborcus' and 'expat'.
>
> I wonder if then our makefiles for liborcus / expat should be fixed to
> take flags set by gb_GCOV at solenv/gbuild/platform/com_GCC_defs.mk:117
> into account?
>
> > Skia (I think) initially also broke the
> > build, but that was because of conflicts between clang and gcc [2], which
> > was resolved when I uninstalled clang. If I understand correctly, it was
> > intended to force skia to always be built with clang, but - intended or
> not
> > - at least on Linux it falls back on gcc (or skia gets skipped perhaps).
>
> Building skia with clang is about helping performance, so you're fine to
> fall back to gcc, probably. Disabling skia completely would mean you
> don't get coverage for the code that integrates skia with the rest of
> LO, which is probably not great.
>
> > When looking at 'coverage.sh', it seems it only covers specific parts of
> > the build, and not everything, so perhaps it doesn't build the parts that
> > fail for me when not setting the additional *FLAGS ?
>
> Yes, coverage.sh is only a partial rebuild, with the idea that if you
> work on an area anyway, then you may want to improve coverage where you
> have domain knowledge. Which has some overlap with your "get a global
> picture" goal, but somewhat different. :-)
>
> > Anyway, if you feel that setting the additional *FLAGS in addition to
> > 'gb_GCOV=YES' is not the right way to address the problem of the full
> build
> > with gcov failing for me, then perhaps we should revisit that thread [1],
> > before we continue looking at why 'make check' fails for me ?
>
> My suggestion would be to just keep the above in mind. Obviously there
> is value in getting a full make check working with coverage *somehow*,
> so if you have a preference how you do that, feel free to go ahead that
> way. It just seemed weird that those global compiler/linker flags are
> set in your build: gb_GCOV is ideally enough to set all of these.
>
> Regards,
>
> Miklos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20220531/b043a10f/attachment.htm>