libreoffice-5.0.4 (libreoffice-5.0.4.2)

[Fernando de Oliveira]

​https://download.documentfoundation.org/libreoffice/src/5.0.4/libreoffice-5.0.4.2.tar.xz

​https://download.documentfoundation.org/libreoffice/src/5.0.4/libreoffice-5.0.4.2.tar.xz.asc

​https://download.documentfoundation.org/libreoffice/src/5.0.4/libreoffice-5.0.4.2.tar.xz.md5

0c6381581f93ef7142b00837002755dd libreoffice-5.0.4.2.tar.xz

​https://www.libreoffice.org/download/release-notes/#fresh

LibreOffice 5.0.4 (2015-12-17) - Fresh Branch

This is the fourth bugfix release of the 5.0.x branch of LibreOffice
which contains new features and program enhancements.  As such, the
version is stable and is suitable for all users. This version may
contain a few annoying bugs which will be fixed in the next bugfix
versions to come. Detailed release notes can be accessed from the list
below.

...

[Fernando de Oliveira]

Ken, LibreOffice-5.0.4 is currently, broken with boost-1.60.0.

Fixed at r16741.

[Pierre Labastie]

I just tried libreoffice-5.0.4.2, with boost-1.60.0, and patch ​http://www.linuxfromscratch.org/patches/downloads/libreoffice/libreoffice-5.0.3.2-boost_1_59_0-1.patch.

It worked for me. I am not sure it always builds OK, because I have built a few optional dependencies (openldap, postgresql), and used them in this build.

Maybe somebody else could test?

[bdubbs@…]

I built this version of libreoffice on Jan 9. I had done boost on Jan 8, but I used --without-system-boost. I don't use libreoffice much, but for those few times it works fine. What is boost supposed to add to the package?

I do notice that the patch seems to just apply a couple of switches, -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED, and a couple of other changes to a bunch of .mk files. Checking the libreoffice files, I can see where the old patch still would apply.

We don't mention the patch in the book. Do we need to? I'd probably not bother to change what we have now.

[ken@…]

We have always tried to use system libraries - boost is unusual in that mostly it is all in the headers, and a new version of boost regularly causes breakage in its user(s). I am still updating my buildscripts (for blfs, I'm now only about 5 weeks behind), then I'll start a fresh build on my test box. I don't link LO to postgresql, and I don't have openldap. Might take me a week or two to get to this.

[bdubbs@…]

I found this link in the advantages of boost:

​http://stackoverflow.com/questions/125580/what-are-the-advantages-of-using-the-c-boost-libraries

Reading that, it strikes me that does not provide any advantages for LFS/BLFS. It seems that its main advantages are cross platform builds and additional libraries. If follows from that if it builds without boost, then we really don't need it.

I see 15 references to boost in BLFS.

Required: exempi, kf5, kdepim, kdepimlibs, akonadi, abiword, ekiga, inkscape

Recommended: clucene, kde-workspace, libreoffice

The rest are optional.

[ken@…]

Replying to bdubbs@…:

I found this link in the advantages of boost:

​http://stackoverflow.com/questions/125580/what-are-the-advantages-of-using-the-c-boost-libraries

Reading that, it strikes me that does not provide any advantages for LFS/BLFS. It seems that its main advantages are cross platform builds and additional libraries. If follows from that if it builds without boost, then we really don't need it.

I see 15 references to boost in BLFS.

Required: exempi, kf5, kdepim, kdepimlibs, akonadi, abiword, ekiga, inkscape

Recommended: clucene, kde-workspace, libreoffice

The rest are optional.

That is not the point. If the build of LO does not use the system version of boost, it will use the version shipped within LO, and any real boost libraries which it happens to use will be the included static versions.

[bdubbs@…]

Good point. However libreoffice will build with the included version of boost. The system version of boost needs a patch to libreoffice. Which is the more trusted way to go?

[Fernando de Oliveira]

And we have to build twice, many times, due to problems with boost. I'd rather keep as is in the book. Long time lost many times, during updates.

Agree with Bruce.

[Pierre Labastie]

Boost is useful for BLFS because it is useful to programmers, and BLFS is a book about compiling programmer's work (aka programs). So no question (I guess), about including it in the book.

The patch used to be mentioned in the book until the text about it was suppressed at last update. I understand that updating libreoffice is a PITA, since it takes so long to build, and that trial and error is just too long a process. But the patch applies cleanly, and the build with system boost is OK. So why not use it?

Let's drop it the next time it is broken.

[bdubbs@…]

There are several packages where boost is required, so we will not be dropping it.

I can live with the case when the libreoffice patch apples cleanly, but if it requires a new patch, I don't think the benefits from an external boost are sufficient to justify the effort needed to wedge it into the package.

Do you want to do the update to add the patch pack into the book?

[Fernando de Oliveira]

Last time or before that it was suppressed from the book, then Ken found a patch.

It has been like thousands of times before, what 1 more time will represent in that.

LO and boost devs do not give a S* to each other.

For years it has been like that.

libreoffice-4.0.3.3-system_boost-1.patch
libreoffice-4.3.1.2-boost_1_56_0-1.patch
libreoffice-4.3.2.2-boost_1_56_0-1.patch
libreoffice-4.3.3.2-boost_1_56_0-1.patch
libreoffice-4.3.4.1-boost_1_56_0-1.patch
libreoffice-4.3.5.2-boost_1_56_0-1.patch
libreoffice-5.0.1.2-boost_1_59_0-1.patch
libreoffice-5.0.2.2-boost_1_59_0-1.patch
libreoffice-5.0.3.2-boost_1_59_0-1.patch
libreoffice-core-3.6.0.4-boost_fix-1.patch
libreoffice-core-3.6.2.2-boost_fix-1.patch

[ken@…]

It's the boost devs who keep breaking things with new releases (years ago I used to use gnash, and that got broken by newer versions of boost).

The reason why LO patches to fix this breakage are hard to find is we always get the new releases of packages, whereas application developers are probably using distros with older versions. Both fedora and sid usually have bleeding-edge development versions of some packages, but for others they manage to keep old versions in use. And AFAICS there are no development snapshots or release candidates of boost - the boost devs have their own regression tests, perhaps they do not care if their changes break projects which use their code.

For development versions of BLFS, temporarily allowing a package to build it own version of a system library is ok if we cannot fix the problem. But I would hope we do not have to do that for releases of BLFS - it might indicate that we are too close to the bleeding edge (i.e. none of the main distros have yet encountered the problem).

[Fernando de Oliveira]

OK.

Whatever you decide, I promise to always update with bundled boost, leaving the test for others, if the patch is necessary or not. I can do this without problem, because a couple of years ago, we had a discussion, Igor was one and probably Ke the other one discussing with me, and we agreed that we do not have enough man power to do everything. That time, I was saying that I would not use the RRR; and everybody concluded that we would not need to have all dependencies.

[Pierre Labastie]

Fair enough Fernando: you update without patch, and when Ken or I (or seomebody else) have time to test, we add the patch if we find one.

As of whether boost devs are not caring, I see that a lot of their fixes have to do with new versions of g++ breaking boost... Sure enough, boost libraries are bleeding edge C++ code, and are likely to expose compiler defects. For me, this is what makes the strength of FOSS: people are always evolving towards (unreachable) perfection.

I'll upload the patch with a new name and update the libreoffice page.

[Pierre Labastie]

Another thought: Actually, the patch fixes bundled versions of packages (libabw, libcdr, ..., they are all in the external directory), which could be built externally and used in libreoffice build by passing the --with-system-... switch. I understand we do not want to have all those deps in the book, because they are used only here. But it may be supposed that recent versions of those deps would build OK with recent versions of boost...