On 04.06.19 19:23, Jan-Marek Glogowski wrote:
Hi everyone,
Am 04.06.19 um 17:01 schrieb Luke Benes:
The decision was to demote release builds, but NOT to remove x86
compatibility. If you take this as an excuse to also end x86 CI testing bots,
you are effectively killing x86 through bit rot. This is not a hypothetical.
As you know, @87 just recently caught a regression introduced by an easyHack
to convert use of sal_uLong to better integer types. Without CI testing,
these bugs will pile up effectively removing x86 compatibility.
IMHO we should "just" switch one of the Jenkins Linux builds to 32bit, not have
an other one. Preferable the gcc release one, as that has smaller object size,
if that is a concern for 32bit (linking etc). Should be fine just to cross-build
on 64bit in a 32bit chroot.
I remember there were some problems because of a missing 32bit Red Hat Developer
Toolset needed for the build, which was AFAIK the real reason to get rid of the
32bit builds - aehmm. Not sure that is now available.
just to reiterate again, we have a docker container setup that builds on
the same CentOS 7 + DevToolset 7 baseline that the 64-bit builds use;
the toolchain is 64-bit, which helps with the OOM issues that used to
plague the 32-bit build.
https://fosdem.org/2019/schedule/event/lightning_talks/attachments/slides/3334/export/events/attachments/lightning_talks/slides/3334/7_Thorsten.odp
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
