On 10/12/20 10:15 PM, Ken Moffat via blfs-dev wrote:
On Mon, Oct 12, 2020 at 09:41:37PM -0500, Bruce Dubbs via blfs-dev
wrote:
I have been struggling today to get a satisfactory build of
mupdf-1.18.0. I can get it to build, but it also builds its own
copies of curl, freeglut, freetype, harfbuzz, lcms2, ligjpeg,
openjpeg, and zlib and links them into the executables.
There is supposedly a way to use system libraries for the above,
but the procedure for using it in this version of the package
breaks the build.
The build procedure for this package is custom. There is a
manually edited Makefile, but no configure. The details of a
build are not documented and difficult to discern when reading the
Makefile.
In BLFS we already have evince and okular that provide the same
functionality as mupdf. Is there any reason to not just archive
mupdf.
http://wiki.linuxfromscratch.org/blfs/ticket/14110
-- Bruce
For *lightweight* PDF viewers I use epdfview and mupdf. On a full
desktop build I eventually install evince, but I tend not to use
that (too awkward, but ISTR it can fill in *some* PDF forms).
Looking at fedora, does what is in
https://src.fedoraproject.org/rpms/mupdf/blob/master/f/mupdf.spec
match what you have been testing ? On a quick look they might be
using using artifex's 'thread-safe' replacement for lcms2, not sure.
They first patch thirdparty/lcms2 for big-endian builds, which we
can happily ignore. But after that they apply
0001-support-PyMuPDF.patch which appears to be a build fix, from (or
updated) earlier this month.
They seem to be using system JBIG2DEC, JPEGXR, and GUMBO which we do not
have. The package certainly doesn't document user.make. I see it now
for the first time. The options -DJBIG_NO_MEMENTO -DTOFU -DTOFU_CJK are
mysterious but appear to have soemthing to do with noto fonts.
I can use that to do some tests, but I don't think it builds a shared
library. Maybe we don't need a library though.
I'll do some more with this tomorrow, thanks.
-------------
I was able to build mupdf with:
cat > user.make << EOF
USE_SYSTEM_FREETYPE := yes
USE_SYSTEM_HARFBUZZ := yes
USE_SYSTEM_JBIG2DEC := no
USE_SYSTEM_JPEGXR := no # not used without HAVE_JPEGXR
USE_SYSTEM_LCMS2 := no # need lcms2-art fork
USE_SYSTEM_LIBJPEG := yes
USE_SYSTEM_MUJS := no # build needs source anyways
USE_SYSTEM_OPENJPEG := yes
USE_SYSTEM_ZLIB := yes
USE_SYSTEM_GLUT := no # need freeglut2-art fork
USE_SYSTEM_CURL := yes
USE_SYSTEM_GUMBO := no
EOF
export XCFLAGS=-fPIC &&
make $BFLAGS build=release &&
make prefix=/usr install
With the above I get:
$ ll -h install/usr/lib
total 50M
-rw-r--r-- 1 bdubbs bdubbs 48M Oct 13 00:02 libmupdf.a
-rw-r--r-- 1 bdubbs bdubbs 2.2M Oct 13 00:02 libmupdf-third.a
$ ll -h install/usr/bin
total 172M
-rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-gl
-rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11
-rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mupdf-x11-curl
-rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 muraster
-rwxr-xr-x 1 bdubbs bdubbs 35M Oct 13 00:02 mutool
If I add 'shared=yes to the 'make install' line, the build time goes
from about 0.1 SBU to 0.7 SBU (at -j22) and the sizes are:
$ ll -h install/usr/lib
total 46M
-rw-r--r-- 1 bdubbs bdubbs 46M Oct 13 10:58 libmupdf.so
$ ll -h install/usr/bin
total 836K
-rwxr-xr-x 1 bdubbs bdubbs 364K Oct 13 10:58 mupdf-gl
-rwxr-xr-x 1 bdubbs bdubbs 72K Oct 13 10:58 mupdf-x11
-rwxr-xr-x 1 bdubbs bdubbs 76K Oct 13 10:58 mupdf-x11-curl
-rwxr-xr-x 1 bdubbs bdubbs 35K Oct 13 10:58 muraster
-rwxr-xr-x 1 bdubbs bdubbs 287K Oct 13 10:58 mutool
The extra time is used during the 'nmake install'. Adding 'shared=yes'
to both the make and install lines fixes the build time.
I think the package is good to go now. Will commit later today.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
