子模块和安装到全局其实没关系，是因为我首先编译安装了mutools到全局，然后再考虑了emacs的事，所以我上面说这是一个很少有让人会遇到的问题（我就是用:load-path关键字管理的reader，和单纯用load-path大概是相同的）。此外，我看了下arch的仓库，也的确是这样打包的，但是它（指libmupdf）还会连带着安装tesseract，我很讨厌这个包又不想引发什么副作用，索性不安装了。
实际上全局安装的这个mupdf对于reader就是多余的，而且似乎还有害。
上面提到的关于全局安装的mupdf和emacs是无关的，只要满足版本号大于26.0就能够在子仓库下指定系统库编译了，仅此而已。奇怪的是，只要我全局编译安装的mupdf的库版本与子仓库内二进制文件所需要的库版本不同reader就会罢工，这显然不是reader的（至少不是主要的）问题。
目前我的reader还是工作得很正常，删掉了编译安装的二进制，并且指定Makefile中libmupdf的版本号为26.2,完全可以像官方README所推荐的那样使用。
我不认为应该冲突。我们即将释放0.3.0版本，移除内置的mupdf（见#18）。如
果你有关于全局和内置版本的问题，只需运行 make clean all 来清空并从零开
始重建。
我们刚刚合并了一个大型分支到主干，我们邀请大家来测试一下。
还是关于我上面提到的问题，它们现在大概解决了，不过我想提一下最近我遇到的几个问题：
Makefile是按照包管理器的存在来判断pkgconf的，这可能会导致一些问题elpaca等包管理器上，安装reader并不是很方便，譬如在上面的例子中我就需要手动修改Makefile来指定mupdf的include路径，有什么办法可以在elisp层面做到这一点么？elpaca的选项，现在是可以的了）libmupdf时，因为其与.so文件硬编码的版本不同，Emacs会被reader堵塞而难以使用，在我手动elpaca-recompile后问题得到了解决。但我注意到了reader会在此时（涉及到动态模块的错误时）堵塞住Emacs，有办法在这种情况下debug么？（现在我在Arch上只使用pacman了）理论上可以用elisp做build system，例如jinx就是这样
我还不太确定第一个问题。请为每个问题在 Codeberg 上创建 Issue。.