When you install jbig2-0.12 and use it (instead of the included copy) to build mupdf-1.7a, the build fails because the installed jbig2.h header includes the not-installed memento.h header. A workaround is to define "-DJBIG_NO_MEMENTO" when building mupdf; but that should not be necessary (or worst case, mupdf should detect it and define it itself).
Fixed in MuPDF commit: commit 17db174004b7d94777d2c3d2d09c8fba629b6e78 Author: Robin Watts <robin.watts@artifex.com> Date: Tue Dec 22 16:47:43 2015 +0000 Update jbig2dec to latest. In particular this takes on the Memento fixes for bug 696183. and in jbig2dec commit: commit cc7ef4a1ef58b01a1548fd988e3eaf344a7f472d Author: Robin Watts <robin.watts@artifex.com> Date: Fri Dec 18 16:14:31 2015 +0000 Move Memento include back into jbig2_priv.h It's clearly nicer not to have Memento as part of the external interface of jbig2, and this solves bug 696183. The include has ping ponged back and forth from jbig2.h in the past due to problems with the jbig2 allocator field naming. We fix that here with a spot of #ifdef/#undef-ery. We also simplify some of the hackery here. Rather than having specific defines such as GSBUILD (meaning 'get memento.h from some place that you magically know about') and JBIG_NO_MEMENTO (meaning 'just ignore memento.h at all'), we now just have JBIG_EXTERNAL_MEMENTO_H. Projects which have their own version of Memento in, and use jbig2dec should define JBIG_EXTERNAL_MEMENTO_H to the location of the memento.h file at build time.