Is it still possible to compile LibreOffice 24 for Linux 32-bit? (part 2)

Wed Feb 14 14:50:35 UTC 2024

Well, thanks to the support of all of you and some figuring on my own, I
was finally able to compile LibreOffice 24.2 for Linux 32-bit.

Let me write about exactly what I did, as it may be helpful for others who
want to compile 24.x on a Debian 12 base.

The source code used is the .tar.xz files available from the official
download section of LibreOffice.

My initial autogen.input

--with-parallelism=16

--with-distro=LibreOfficeLinux

--with-lang=es

--with-myspell-dicts

--enable-release-build

--with-package-format=deb

--disable-dependency-tracking

--with-jdk-home=/usr/lib/jvm/java-17-openjdk-i386/

--with-privacy-policy-url=NO-URL

Running 'make' alone fails because all warnings are treated as errors, so I
added the following parameters

make CFLAGS="-Wno-error" CXXFLAGS="-Wno-error -g1"

However, it still stops with the following error:

-----

CoinFinite.cpp: In function 'bool CoinFinite(double)':

CoinFinite.cpp:38:19: error: 'DBL_MAX' was not declared in this scope

38 | return val != DBL_MAX && val != -DBL_MAX;

| ^~~~~~~

CoinFinite.cpp:8:1: note: 'DBL_MAX' is defined in header '<cfloat>'; did
you forget to '#include <cfloat>'?

7 | #include "CoinUtilsConfig.h"

+++ |+#include <cfloat>

8 |

make[5]: *** [Makefile:675: CoinFinite.lo] Error 1

------

By looking at
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/UnpackedTarball/coinmp/CoinUtils/src/CoinFinite.cpp,
it cannot find "cfloat", so I added "#include <cfloat>" at the first line.

Then a new problem appeared.

-------

css_types.cpp:9:10: fatal error: mdds/sorted_string_map.hpp: No such file
or directory

9 | #include <mdds/sorted_string_map.hpp>

| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

compilation terminated.

make[5]: *** [Makefile:1289: css_types.lo] Error 1

make[4]: *** [Makefile:2356: all-recursive] Error 1

make[3]: *** [Makefile:1466: all-recursive] Error 1

make[2]: *** [Makefile:1375: all] Error 2

make[1]: ***
[/home/linux/Downloads/libreoffice-24.2.0.3/external/liborcus/ExternalProject_liborcus.mk:85:
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/ExternalProject/liborcus/build]
Error 1

make[1]: *** Waiting for unfinished jobs....

-----

The css_types.cpp file requires mdds/sorted_string_map.hpp, but there is no
mdds folder under this file! So,

mkdir mdds

cp -r
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/UnpackedTarball/mdds/include/*
.

I ran again ‘make’ with the already mentioned parameters. New error:

------

measurement.cpp:12:10: fatal error: mdds/sorted_string_map.hpp: No such
file or directory

12 | #include <mdds/sorted_string_map.hpp>

| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

compilation terminated.

make[5]: *** [Makefile:2102: liborcus_0.18_la-measurement.lo] Error 1

make[4]: *** [Makefile:2356: all-recursive] Error 1

make[3]: *** [Makefile:1466: all-recursive] Error 1

make[2]: *** [Makefile:1375: all] Error 2

make[1]: ***
[/home/linux/Downloads/libreoffice-24.2.0.3/external/liborcus/ExternalProject_liborcus.mk:85:
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/ExternalProject/liborcus/build]
Error 1

make[1]: *** Waiting for unfinished jobs....

------

So I copied the newly created mdds folder to liborcus with

cp -r mdds/
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/UnpackedTarball/liborcus/src/liborcus/

After this, a new error appears after running make:

-----

ClpHelperFunctions.hpp:16:4: error: #error "don't have header file for math"

16 | # error "don't have header file for math"

| ^~~~~

make[5]: *** [Makefile:931: ClpCholeskyBase.lo] Error 1

make[4]: *** [Makefile:693: all] Error 2

make[3]: *** [Makefile:519: all-recursive] Error 1

make[2]: *** [Makefile:234: all-recursive] Error 1

make[1]: ***
[/home/linux/Downloads/libreoffice-24.2.0.3/external/coinmp/ExternalProject_coinmp.mk:31:
/home/linux/Downloads/libreoffice-24.2.0.3/workdir/ExternalProject/coinmp/build]
Error 1

-----

And appeared a lot of errors that look like:

-----

rdf_model.c:1891:17: error: invalid use of incomplete typedef
'librdf_model' {aka 'struct librdf_model_s'}

1891 | return model->factory->transaction_get_handle(model);

rdfinit.c:162:10: error: invalid use of incomplete typedef 'librdf_world'
{aka 'struct librdf_world_s'}

162 | world->genid_base = 1;

-----

Now I installed librdf0-dev and its dependencies, and added the following
lines to autogen.input:

--with-system-redland

--disable-coinmp

Ran autogen.sh and make with the already mentioned parameters and…
success!, even though in the process there were a lot of daunting warnings
like this one:

-------

58: warning: argument 1 value ‘4294967295’ exceeds maximum object size
2147483647 [-Walloc-size-larger-than=]

322 | pShapes.reset(new SwAccessibleObjShape_Impl[rSize]);

-------

I'm not sure if adding --disable-coinmp was a good idea (I don't even know
what it's for!), but the resulting binaries seem to work fine. Just in
case, I removed --disable-coinmp and added --with-system-coinmp to
autogen.input. Then I installed coinor-libcoinmp-dev and its dependencies.
Ran autogen.sh and make again. Compilation was also successful.

El vie, 9 feb 2024 a las 17:53, Escuelas Linux (<escuelaslinux at gmail.com>)
escribió:

> Thanks to Dan Horák and Rene Engelhard for their answers!
>
> Dan said:
>
>
> -"Because 32-bit system means max 4GB address space for a process and ld
> runs as a single process".
>
>
> I installed a PAE kernel, so it can effectively use more than 4 GB.
>
>
> -"You can try disabling or reducing the size of debuginfo to reduce the
> size of the *.o files if it's used, you can disable LTO and there are some
> options for ld to reduce its memory usage a bit".
>
>
> I tried several permutations to reduce the amount of memory used. One of
> them was to reduce the number of processors in my autogen.input:
>
>
> --with-parallelism=1
>
>
> Another one was to add this parameter when running make:
>
>
> make LDFLAGS="-Wl,--reduce-memory-overheads"
>
>
> I also increased the available memory on the VM from 12 to 15 GB. But no
> results, always got the exhausted memory message.
>
> I also tried several other possible solutions, but it feels like going on
> a wild goose chase without knowing exactly what to do, relying on some
> general random advices found on the web.
>
> -------------
>
> Rene said:
>
>
> -"Debian still ships LibreOffice on 32bit archs, as do other
> distributions."
>
>
> Oh! Thanks for the tip! I was not aware that Debian even has binary
> LibreOffice 24.2 32-bit packages, albeit in the unstable branch.
>
> I was even able to build LibreOffice from source:
>
>
> apt-get --build source libreoffice
>
>
> This proves to me that the LibreOffice source code has not dropped 32-bit
> support, but I still don't know why my own compilation attempts always
> failed with a memory exhausted message, even with the same VM configuration.
>
> Would it be possible for me to just use the Debian LibreOffice 24.2
> binaries or its source packages? Not quite, as they also have a lot of
> dependencies on packages that are only available in the unstable branch, so
> they would not be suitable for a distribution intended for a stable Debian
> 12 bookworm base.
>
>
> -"I do -g1 in Debian. LTO works".
>
>
> Where should I add the -g1 parameter?
>
>
> -"make check fails. I do a minimal set (testtools bridgetest, smoketest,
> sal, the other public libraries) to at least not get something
> fundamentally broken".
>
>
> My autogen.input file is:
>
> --with-parallelism=16
>
> --with-distro=LibreOfficeLinux
>
> --with-lang=es
>
> --with-myspell-dicts
>
> --enable-release-build
>
> --with-package-format=deb
>
> --disable-dependency-tracking
>
> --with-jdk-home=/usr/lib/jvm/java-11-openjdk-i386/
>
> --with-privacy-policy-url=NO-URL
>
>
> -"And somehow the testtools bridgetest fails when building with gcc >= 13,
> 12 works. Haven't found a solution yet.)"
>
>
> I'm using gcc 13! Maybe this could be the cause of my compilation failures?
>
> I'll make some more attempts to compile LibreOffice 32-bit now using gcc
> 12, any additional ideas or suggestions would be more than welcome.
>
>
> Thanks again.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20240214/f94aed30/attachment.htm>