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. ĸen -- The people next door oppress me all night long. I tell them: I work all day, a man's got to have some time to learn to play the tuba. That's oppression, that is. [ Guards! Guards! ] -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
