On Mon, Jun 03, 2019 at 04:57:52AM +0200, Christopher Gregory via blfs-support wrote: > > > > On Sun, Jun 02, 2019 at 11:16:15AM +0200, Christopher Gregory via > > blfs-support wrote: > > > Hello, > > > > > > I have just finished installing libreoffice, but noticed early on in the > > > build that it failed with the following error: > > > > > > /usr/include/c++/9.1.0/memory:179:3: error: template with C linkage > > > 179 | template<typename _Tp, typename __ = > > > _Require<__not_<__is_pair<_Tp>>>, > > > | ^~~~~~~~ > > > > > > After typing that error into google, I found that a gentoo user had filed > > > a bug report: > > > > > > https://lists.freedesktop.org/archives/libreoffice/2019-March/082342.html > > > > > > It seems that this is a bug or change introduced by icu developers. The > > > link in the above list to the patch, seems to only be for the binary > > > version that gentoo uses. A further search found that there are a few > > > files that need to be patched in icu, to allow it to successfully build > > > libreoffice. Before I tried the suggested patches, I tested the build > > > with the "internal" version of icu and the build failed with the same > > > error. > > > > > > I have not been able to find normal ".patch" files for the needed > > > changes, however, manually editing each of the files with the contents > > > found below, allow a successful compile and install of libreoffice: > > > > > > https://github.com/unicode-org/icu/pull/572/files > > > > > > Please note that this is on a clean install of lfs/blfs, so there are NO > > > versions earlier than what is published in the current svn version of the > > > book. That is the ONLY way to fairly test this. > > > > > > Regards, > > > > > > Christopher. > > > > Hi Christopher, > > > > I hit this at the beginning of last month, at that time I was using > > 6.2.2.2. When I got a little further, in > > http://lists.linuxfromscratch.org/pipermail/blfs-dev/2019-May/036062.html > > I discovered that xmlsec1 was the real problem, and has been fixed > > in xmlsec1-1.2.28. > > > > But on a slightly newer build with gcc-9.1 gcc, Bruce did not have a > > problem and nobody else chimed in. I'm currently on my 'tuning' > > attempts (packages mostly frozen at versions from April), but when I > > built a slightly newer system in early May I again needed to use > > system xmlsec. > > > > xmlsec1-1.2.28 > > ./configure --prefix=/usr --disable-static > > make ; make install > > > > From what I wrote in that thread, there may be tests, but I have > > not attempted to run them. > > > > > > libreoffice: --with-system-xmlsec > > > > > Hello Ken, > > That is odd on a clean build for everyone to not get the issue. This build I > have been doing for just over a week to get blfs working. It is said by the > same gentoo bug reporter that xml is indeed in part responsible, but by only > editing the files as stated in the link, they are all icu files, and the > patches are on icu's git hub account. So in this instance, I find myself > tending to think that it was, at least in my case and the gentoo persnons icu > to be the issue. I am wondering, if perhaps it might be an issue with what > processors we are using, ie amd64. I think I recall other packages being > prone to this in the past. > Not related to processors: my initial testing was on intel (haswell). But I have no idea how many people have built libreoffice with icu_64 on fresh systems. If people upgrade in-place without removing all the old files, that maybe explains it.
And my reading from the eventual comment on the icu bug or pull request was that the change to icu just papered over the problem, and that fixing upstream xmlsec was the correct solution. But I nearly missed that late comment when I was first looking at this. OTOH, perhaps there are people not seeing this on fresh builds. If so, my own switches for LO were at the end of the -dev thread, and Bruce's (which looked similar on a *quick* check) were in the post 1 or 2 before that. No doubt, one day, somebody will say "You fool, ken, the difference is ...". Unfortunately, as you have found recently, what affects one builder might not affect another. My gut feeling is that xmlsec1 should be pulled into the book. But for the moment I'm more interested in the "fun"[1] of using cheap security fixes, and then looking again at dvisvgm now that I know _how_ asy can use it. Following comments are not related to libreoffice, xmlsec, or icu. ĸen 1. As I posted earlier, boost needs special treatment of defines in CXXFLAGS, and (as I think I said) c-ares gets all grumpy and wants them in CPPFLAGS. But sox (which happens to be a critical part of my desktop toolkit) burns CPU with -D_FORTIFY_SOURCE=2. I found an old reference to this, and have now dropped that from my sox builds. Definitely fun, will try with -fstack-protector-strong on my next build. 1.1 For most packages, the effect of -D_FORTIFY_SOURCE=2 on build times is either lost in the noise, or just a few percent. But sometimes, e.g. fftw which we now build in 3 variants, or texlive-source, the difference is significant. But the effect on runtimes is usually just a minor slowdown. ĸen -- Before the universe began, there was a sound. It went: "One, two, ONE, two, three, four" [...] The cataclysmic power chord that followed was the creation of time and space and matter and it does Not Fade Away. - wiki.lspace.org/mediawiki/Music_With_Rocks_In -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
