On Thu, Feb 06, 2020 at 07:11:07PM +0000, Ken Moffat via blfs-dev wrote:
> On Wed, Feb 05, 2020 at 08:19:51PM +0000, Ken Moffat via blfs-dev wrote:
> > With LO-6.4.0.3 '-disable-gtk' is no longer recognized.
> >
> > Confusingly the error report says:
> > unrecognized option --disable-gtk
> >
> > (note the two dashes there), but I confirmed that I only had one
> > dash like the book says. Looking at the configure script, only gtk3
> > gets mentioned.
> >
> > That might mean we can remove the '-enable-gtk3' but I have not
> > tested that (nor looked at which version of libfreehand it downloads,
> > to see if we can reinstate system ICU), that review might happen
> > after I've finished my full build (I'm planning to update the
> > versions of a lot of the dependant perl modules, usually that is
> > painful).
> >
>
> Good news and bad news.
>
> The good news:
>
> The default is to use gtk3 on this platform, so both -disable-gtk
> and -enable-gtk3 can be dropped.
>
> Also, although in December I blamed libfreehand for the failure to
> build against ICU_65 and the version of libfreehand has not changed,
> the internal icu is now 65 and it certainly appears to build with
> system icu. Perhaps the dep for libfreehand (librevenge) is
> involved. Dunno.
>
> The bad news:
>
> I can't confirm that it will install with system icu because at the
> moment I don't want to override my much bigger install from
> Wednesday (lots more languages) and I cannot persuade it to do a
> DESTDIR install (or distro-pack-install). The distro-install-
> scripts seem to know how to handle DESTDIR, but it doesn't seem to
> get passed to them.
>
> <sigh/> I'd forgotten what a pain LO can be.
>
Update: I suspect yesterday was just another day where I proved I'm
not up to doing this :-(
Still not sure what triggered the DESTDIR problems, but along the
way I tried _exporting_ DESTDIR without success, and then came back,
with it still set in my environment, and got nowhere. In the
meantime I looked at fedora and debian :
Fedora: poppler-0.84.0 works, according to a past commit about
rebuilding for it, and they later added a patch to fix building with
poppler-0.83.0 (i.e. adds some stuff only if version is 0.83.0).
Unfortunately, I'm already on 0.85.0 and that fails -
[build ZIP] templates/styles/Modern.ott
/scratch/ken/libreoffice-6.4.0.3/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:
In function ‘int main(int, char**)’:
/scratch/ken/libreoffice-6.4.0.3/sdext/source/pdfimport/xpdfwrapper/wrapper_gpl.cxx:71:37:
error: no match for ‘operator=’ (operand types are
‘std::unique_ptr<GlobalParams>’ and ‘GlobalParams*’)
71 | globalParams = new GlobalParams();
| ^
(etc.)
At least that fail happened quickly with 8 cores.
As I think I've said before, I loathe poppler updates, they seem to
be designed to break other packages. So, using system poppler is
still not an option for us.
Oh, and fedora's specfile (still) has a comment to look at
distro-pack-install.
From debian unstable (earlier 6.4.0) I see they are using
distro-pack-install with a DESTDIR in the build tree, so I've just
tried that and it worked, I guess soemthing else went wrong before
my first attmept yesterday.
Also from debian: prefix the autoconf invocation with PYTHON=python3
and that too appears to work, although I did have python2 available
if anything decided to use it.
TLDR: I think we can reinstate system icu and use python3, as well
as dropping the gtk/gtk3 switches (but mention the alternatives for
building with kde).
Quite a lot more to do (e.g. install all the book's deps to allow
e.g. java) before I confirm this.
ĸen
--
We had folksingers in the lower bar for six months back home where
I worked. In the end we had to get a man in with a ferret.
-- Polly, in "Interesting Times"
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
