Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose <d...@debian.org>: >On 29.10.19 15:09, Vincent Lefevre wrote: >> On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: >>> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre ><vinc...@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.