<div dir="ltr">Hi,<div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 11, 2022 at 9:07 PM Thorsten Behrens <<a href="mailto:thb@libreoffice.org">thb@libreoffice.org</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">Hi Maarten,<br>
<br>
Maarten Hoes wrote:<br>
> I personally do not know enough about the build system to figure out how to<br>
> correct this. Any and all help in trying to make this work again would be<br>
> appreciated.<br>
> <br>
Beyond what Lubos suggested, and assuming your error happens fairly<br>
quickly - you might want to give 'git bisect run' a try to find the<br>
commit that broke this (assuming you remember a time when it last<br>
worked).<br>
<br>
Here's a howto: <a href="https://lwn.net/Articles/317154/" rel="noreferrer" target="_blank">https://lwn.net/Articles/317154/</a><br>
<br>
HTH,<br>
<br>
-- Thorsten<br></blockquote><div></div><div><br></div><div><br></div><div><br>I thought about giving this a go, but have some questions.<br><br><br><br>1.)<br>The last known good commit for me, was way back in 2015. It seems to me that it would literally take weeks if not longer (on my vm, a full libreoffice build takes about an hour) to find the right commit ? I realize the process is automatic, but I still would have to keep my PC and VM running for that time. Am I exaggerating the time it would take to find the offending commit ?<br><br><br><br><br>2.)<br><br>I guess that 'git bisect run' considers things a 'success' if the build succeeds (zero exit code), and a 'failure' if the build fails (non zero exit code). Duh. But I don't get the impression that it matters to git what it exactly was that made the build fail ?  I mean, what if there were multiple build breakages between 'good commit' and 'bad commit', but you are only looking for a specific failure (gcov related), and not possible others that also broke the build ? I know you can limit the build to specific build targets, which would make this less likely from occurring, with 'make -C external Module_foo'. But when I tried this like this :<br><br>make clean<br>./autogen.sh --enable-python=internal --without-system-libs --without-system-headers<br>verbose=t make --output-sync=target -C external Module_liborcus<br><br>I get a build error :<br><br>/bin/sh: line 1: /home/maarten/src/libreoffice/core/workdir/LinkTarget/Executable/concat-deps: No such file or directory<br>make: *** [/home/maarten/src/libreoffice/core/solenv/gbuild/LinkTarget.mk:842: /home/maarten/src/libreoffice/core/workdir/LinkTarget/StaticLibrary/libboost_filesystem.a] Error 127<br>make: Leaving directory '/home/maarten/src/libreoffice/core/external'<br><br>Presumably because there are some prerequisites that are missing, that 'normally' (when you do a full build) do get build before the external projects are build, but that are now missing ? Is there a way around this ? Perhaps there is a specific make target that builds those prereqs, so you can do 'make -C external Module_foo' on an otherwise 'make clean'ed build ?<br><br><br><br>3.)<br>Would it be the correct way to run 'git bisect run', if I had a shell script like this :<br><br>$ cat foo.sh<br>#!/bin/sh<br>cd  /home/maarten/src/libreoffice/core<br>make clean<br>./autogen.sh --enable-python=internal --without-system-libs --without-system-headers<br>gb_GCOV=YES verbose=t make --output-sync=target<br><br>and I then ran<br><br>git bisect start <failing commit> <passing commit><br>git bisect run foo.sh<br><br><br><br><br>- Maarten <br></div></div></div>