Compiling LO for lcov/gcov code coverage fails (gb_GCOV=YES)

[Maarten Hoes]

On Fri, May 13, 2022 at 10:37 AM Stephan Bergmann <sbergman at redhat.com>
wrote:

> On 5/12/22 15:44, Maarten Hoes wrote:
> > What I *think* I see happening, is that the '-fprofile-arcs
> > -ftest-coverage -lgcov' flags are correctly being set on the
> > commandlines, up until were the error occurs, which is where (i think)
> > linking against libpng is attempted (see error below). I tried setting
> > *FLAGS in 'external/libpng/StaticLibrary_libpng.mk', but that did not
> > change things. Am I misunderstanding what is happening here, or perhaps
> > modifying the wrong Makefile ? I cannot really tell what is going on
> > here, or what to try next.
>
> I guess it just doesn't work well to link an archive like
> workdir/LinkTarget/StaticLibrary/liblibpng.a built with GCC and
> -fprofile-arcs into a library like Library_skia built with Clang and
> -fprofile-arcs:  GCC -fprofile-arcs embeds calls to __gcov_init etc.
> into the code (satisfied at link time from GCC's libgcov.a) while Clang
> -fprofile-arcs embeds calls to llvm_gcov_init etc. into the code
> (satisfied at link time from Clang's libclang_rt.profile-*.a).  The way
> that normally works is that when you use g++ -fprofile-arcs for linking,
> it sneaks in a -lgcov towards the end of the command line that it passes
> to the linker, and when you use clang++ -fprofile-arcs for linking, it
> sneaks in a /path-to/libclang_rt.profile-*.a towards the end of the
> command line that it passes to the linker.  You have (multiple, even)
> explicit -lgocv on your clang++ -fprofile-arcs command line for linking
> Library_skia, but that comes too early before the -Wl,--start-group ...
> $W/LinkTarget/StaticLibrary/liblibpng.a ... -Wl,--end-group, so can't be
> used to satisfy that archive's dependency on __gcov_init etc.  (And the
> later, sneaked in, /path-to/libclang_rt.profile-*.a doesn't satisfy
> those dependencies either, as it rather supplies llvm_gcov_init etc.)
>
> Maybe it would be best if the decision to force using Clang for building
> Library_skia would be explicitly opt-in or opt-out.
>
>

Hi,

Thank you for taking the time to explain that.

I was about to try to compile everything with clang (instead of a gcc/clang
mix) in an attempt to work around this, but now that I am starting to think
some more about your explanation, I guess that clang also doesn't play nice
with lcov (which I was planning to use once the build succeeded).

As far as I can tell right now, using gcc to build everything would be the
ideal situation for my use case. But of course, I don't know why the
decision was made to always build skia with clang instead of gcc: does the
build fail with gcc, does it compile but not run correctly, are the
resulting binaries larger/slower, etc. ?


- Maarten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20220513/4dc7be46/attachment.htm>