Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit?

[Christian Lohmaier <lohmaier@xxxxxxxxxxxxxx>]

Hi Carl, *,

On Sat, Mar 9, 2024 at 9:06 PM Carl Spitzer {L Juno} <lynux@xxxxxxxx> wrote:
>
> On Wed, 2024-02-07 at 12:51 -0600, Escuelas Linux wrote:
>
>  The release notes for the latest version of LibreOffice (24.2) state that
>
>
> "The minimum requirements for building and running LibreOffice on Linux have been raised from Red Hat Enterprise Linux 7/CentOS 7 to Red Hat Enterprise Linux 8/CentOS 8 (or equivalent)".

The runtime baseline only really applies to builds provided by TDF /
those that are done on that baseline. And stating that baseline for
building LibreOffice just is an indicator as to what the
tested/supported versions of various tools that are used during the
build are/anything older than that is not supported.

> Since Red Hat/CentOS 8 does not have a 32-bit edition, I wonder if my problems compiling for 32-bit are due to a possible lack of support.

Well, that was one of the reasons TDF decided to not offer 32bit
versions for linux anymore (already a problem with CentoOS 7 and the
devtools collection), along with that most linux users are using their
distro's version anyway/they don't need the linux binaries from TDF.

> Tumbleweed Opensuse is 32 bit bleeding edge.

So that in itself isn't a reason why 32bit builds won't work - the
problem in this thread was just that the compiler/linker ran out of
memory/hit a 32bit memory limit, and easiest solution here is to not
use the mergedlibs switch or not build with debuginfo/use options that
create less debuginfo.

LibreOffice project still accepts buildfixes for 32bit linux of course
in case there are some incompatibilities that are found, and 32bit is
still build-tested by CI on Windows/TDF also still provides 32bit
Windows binaries / breaking 32bit linux is unintentional, but can
happen, but we rely on downstream builders to detect them and in turn
notify us, ideally with a compile-fix.
Fundamental issues like linker running out of memory is nothing we can
realistically influence by changing the codebase, but we can of course
change the default linker flags if there are options that require less
memory/would prevent the issue that way or add a warning that 32bit
along with debuginfo and mergedlibs will likely run out of memory as a
hint for the user.

ciao
Christian