<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 13, 2022 at 10:37 AM Stephan Bergmann <<a href="mailto:sbergman@redhat.com">sbergman@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/12/22 15:44, Maarten Hoes wrote:<br>
> What I *think* I see happening, is that the '-fprofile-arcs <br>
> -ftest-coverage -lgcov' flags are correctly being set on the <br>
> commandlines, up until were the error occurs, which is where (i think) <br>
> linking against libpng is attempted (see error below). I tried setting <br>
> *FLAGS in 'external/libpng/StaticLibrary_libpng.mk', but that did not <br>
> change things. Am I misunderstanding what is happening here, or perhaps <br>
> modifying the wrong Makefile ? I cannot really tell what is going on <br>
> here, or what to try next.<br>
<br>
I guess it just doesn't work well to link an archive like <br>
workdir/LinkTarget/StaticLibrary/liblibpng.a built with GCC and <br>
-fprofile-arcs into a library like Library_skia built with Clang and <br>
-fprofile-arcs:  GCC -fprofile-arcs embeds calls to __gcov_init etc. <br>
into the code (satisfied at link time from GCC's libgcov.a) while Clang <br>
-fprofile-arcs embeds calls to llvm_gcov_init etc. into the code <br>
(satisfied at link time from Clang's libclang_rt.profile-*.a).  The way <br>
that normally works is that when you use g++ -fprofile-arcs for linking, <br>
it sneaks in a -lgcov towards the end of the command line that it passes <br>
to the linker, and when you use clang++ -fprofile-arcs for linking, it <br>
sneaks in a /path-to/libclang_rt.profile-*.a towards the end of the <br>
command line that it passes to the linker.  You have (multiple, even) <br>
explicit -lgocv on your clang++ -fprofile-arcs command line for linking <br>
Library_skia, but that comes too early before the -Wl,--start-group ... <br>
$W/LinkTarget/StaticLibrary/liblibpng.a ... -Wl,--end-group, so can't be <br>
used to satisfy that archive's dependency on __gcov_init etc.  (And the <br>
later, sneaked in, /path-to/libclang_rt.profile-*.a doesn't satisfy <br>
those dependencies either, as it rather supplies llvm_gcov_init etc.)<br>
<br>
Maybe it would be best if the decision to force using Clang for building <br>
Library_skia would be explicitly opt-in or opt-out.<br>
<br></blockquote><div><br></div><div><br></div><div>Hi,<br><br>Thank you for taking the time to explain that.<br><br>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). <br><br>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. ?<br><br><br>- Maarten</div><div> </div></div></div>