Re: We'd like to continue the production of the 32-bit deb packages

For some reason, I always thought that Debian was the OS used to produce
the Linux distro-agnostic binaries, but I proved wrong when did a test on
Debian 9 (as Debian 10 could not be have been used previously due its
recent release date). Debian 9 indeed includes a very old C/C++ compiler
unable to work with relatively recent versions of LibreOffice, and seems to
be an ugly hassle to try to update its compiler.

If the Red Hat Developer Toolset is the answer, that would mean that the OS
adequate to produce distro-agnostic deb and rpm packages is Red Hat or
CentOS? Either way, doing that would be a very steep endeavor for our
limited experience. We are not aware of documented procedures to produce
LibreOffice distro-neutral binaries, or how to setup a system capable of
achieving that feat. AFAIK, the guy or gal that was responsible for
producing the 32-bit neutral TDF LibreOffice deb and rpm packages didn't
seem to step in this thread, so his/her real life experience, know-how and
expertise on pitfalls and errors avoidance could now be lost on the demise
of the Linux 32-bit support. That's really sad, at least for us. :'(

Butt, with the help of all you guys, we managed to solve the issue for our
own distribution, although we would have loved to offer 32-bit
distro-neutral deb packages for anyone else. But, who knows, maybe in fact
is not worth the effort, given the tiny amount of downloads that prompted
TDF to shutdown the release of binaries for this architecture.

El mar., 20 ago. 2019 a las 7:38, Stephan Bergmann (<sbergman@redhat.com>)
escribió:

> On 16/08/2019 20:43, dreamnext@gmail.com wrote:
> > What we did if after a ‘make’ with errors, we had to ran ‘make
> > build-nocheck’ to be able to bypass those errors on a Debian 10 schroot
> > environment. This time, the required debs files were produced. However,
> > when installing those debs and trying to run LibreOffice on Escuelas
> > Linux (the main target distribution) it does not work, as it complains
> > about a glibc mismatch version. So, it seems that the generated deb
> > files are not distribution-independent as the ones that were previously
> > released by The Document Foundation.
>
> Note that producing builds that are compatible with our baseline (as
> spelled out in README.md) is a non-trivial endeavour.  You typically do
> such builds on a baseline machine to make sure you do not link against
> functionality in e.g. libc.so.6 that is only available in newer versions
> of that library.  However, a baseline machine typically has a C++
> compiler that is too old for our needs, so you need a newer compiler but
> which generates code that only links against functionality that is
> already available in the baseline libstdc++.so.6 (e.g., by using Red Hat
> Developer Toolset).