Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi,
Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose <doko@debian.org>:
>On 29.10.19 15:09, Vincent Lefevre wrote:
>> On 2019-10-29 13:09:46 +0100, rene.engelhard@mailbox.org wrote:
>>> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre
><vincent@vinc17.net>:
>>>> In case makefile magic triggers some rebuild, you can also run the
>>>> generated executable directly (with the right environment
>variables,
>>>> in case this matters). If the programs honors the system ABI, this
>>>> is allowed, and you'll effectively test the new libstdc++6.
>>>
>>> No, if the rebuild rebuilds cppunittester or one of the
>>> exceptionprotectors or the smoketest so or similar we are at the
>>> same situation as with the autopkgtest (that's what it builds) and
>>> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the
>>> test are an executable it's a executable with gazillions of .sos.
>>
>> I meant running the generated program (smoketest) without rebuilding
>> it:
>>
>> 1. Build smoketest with the old g++-9 / libstdc++6.
>> 2. Upgrade g++-9 / libstdc++6.
>> 3. Run smoketest directly.
>>
>> (I assume that the smoketest executable does not invoke g++-9 to
>> rebuild things on the fly.)
>
>I'm not sure if Rene wants to help tracking this down, he just disabled
>running
>the test in
>https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494
*temporarily*
>and introducing a typo in
>https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b
>So maybe don't commit if you are angry.
>
Maybe, yes, but I needed to get it builds le got the upload. Will fix, thanks.
><_rene_> how supported is clang on the various (release) archs?
><_rene_> completely?
><_rene_> (clang++ if it matters)
><_rene_> (actually probably only matters for amd64/arm64 for now,
>but...)
>
>so I assume we cannot expect Rene's help for that issue anymore.
Unfortunately the tests fail when LO is built with clang. So yes, we need to track it down.
>The comment about cppunit made me look at the cppunit package to find
>#935902,
>and yes, the test case is reproducible. So looking at the test failure
>would
>have been revealed that the test frame work is broken, not a single
>test.
I said in some comment that "the first" test failed: basic_scanner.
I didn't say smoketest was the only one. It's the only one done in autopkgtest though.
This
>turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage
>in
>cppunit. The fix is now in -16.
Ok. Will try. Then I can add build-conflcts or so and reenable the tests.
>So a symbols file and a test rebuild should have at least flagged
>something, however cppunit doesn't have symbols files, because the
>package
>maintainer doesn't like them.
For C++ and the mangling and handling it in all arxgs, yes.
> And afaik there was no test rebuild for
bullseye
>l either.
It does not help to blame people for not doing a rebuild when there is no rebuild necessary.
Regards
Rene
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Reply to: