[Question] mupdf, mupdf-third: static libs or dynamic libs needed? ?

[Mark-Joy]

When compiling pymupdf from source, it needs mupdf and mupdf-third libs. Could you please clarify which kind of libs they are?
As per my experience, mupdf-third is static lib while mupdf is dynamic lib.

[JorjMcKie]

I am not sure embarrassingly. All I know is that MuPDF needs to be built with CLAGS="-fPIC". Sounds like dynamic to me.

[Mark-Joy]

It seems that from 1.18, mupdf no longer provide libmupdf-third.so (dynamic lib): https://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg475799.html
So it may not be actually required by pymupdf.
But you can still get libmupdf-third.a by running static build of mupdf.

In my build, to get pymupdf compiled successfully, I had to build libmupdf-third.a separately from libmupdf.so

If it may not be required, could you please remove mupdf-third from setup.py?

[Mark-Joy]

Since 1.18.0, mupdf no longer produced libmupdf-third.so in its build, so I tried removing mupdf-third in setup.py of PyMuPDF.
mupdf 1.19.0 + PyMuPDF 1.19.1 installed successfully and seems to work fine without mupdf-third.

[JorjMcKie]

Ok, thanks for digging this out.
I will remove that lib from the setup.py then.

[JorjMcKie]

Just tried to compile under Linux: that does not work:

x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.8/fitz/fitz_wrap.o -lmupdf -o build/lib.linux-x86_64-3.8/fitz/_fitz.cpython-38-x86_64-linux-gnu.so
//usr/local/lib/libmupdf.a(load-jpx.o): In function `jpx_read_image':
load-jpx.c:(.text.jpx_read_image+0x83): undefined reference to `opj_set_default_decoder_parameters'
load-jpx.c:(.text.jpx_read_image+0xa3): undefined reference to `opj_create_decompress'
load-jpx.c:(.text.jpx_read_image+0xbd): undefined reference to `opj_set_info_handler'
load-jpx.c:(.text.jpx_read_image+0xcf): undefined reference to `opj_set_warning_handler'
load-jpx.c:(.text.jpx_read_image+0xe1): undefined reference to `opj_set_error_handler'
load-jpx.c:(.text.jpx_read_image+0xf1): undefined reference to `opj_setup_decoder'
load-jpx.c:(.text.jpx_read_image+0x103): undefined reference to `opj_stream_default_create'
load-jpx.c:(.text.jpx_read_image+0x131): undefined reference to `opj_stream_set_read_function'
load-jpx.c:(.text.jpx_read_image+0x140): undefined reference to `opj_stream_set_skip_function'
load-jpx.c:(.text.jpx_read_image+0x14f): undefined reference to `opj_stream_set_seek_function'
load-jpx.c:(.text.jpx_read_image+0x161): undefined reference to `opj_stream_set_user_data'
load-jpx.c:(.text.jpx_read_image+0x16c): undefined reference to `opj_stream_set_user_data_length'
...

[JorjMcKie]

Tried with this setup.py:

DEFAULT = [
    "mupdf",
    # "mupdf-third",
]

ALPINE = DEFAULT + [
    "jbig2dec",
    "jpeg",
    "openjp2",
    "harfbuzz",
]
ARCH_LINUX = DEFAULT + [
    "jbig2dec",
    "openjp2",
    "jpeg",
    "freetype",
    "gumbo",
]
OPENSUSE = ARCH_LINUX + [
    "harfbuzz",
    "png16",
]
FEDORA = ARCH_LINUX + [
    "harfbuzz",
    "leptonica",
    "tesseract",
]
NIX = ARCH_LINUX + ["harfbuzz"]
LIBRARIES = {
    "default": DEFAULT,
    "ubuntu": DEFAULT,
    "arch": ARCH_LINUX,
    "manjaro": ARCH_LINUX,
    "artix": ARCH_LINUX,
    "opensuse": OPENSUSE,
    "fedora": FEDORA,
    "alpine": ALPINE,
    "nix": NIX,
}

...

[Mark-Joy]

What I did are:

• Removed all previous version of mupdf libs in /usr/lib/: libmupdf.a, libmupdf.so, libmupdf-third.a
• Compiled mupdf 1.19.0 shared lib with below command:
  make HAVE_X11=no HAVE_GLUT=no shared=yes build=release install
  It gave me libmupdf.so (dynamic lib) in /usr/lib/
  In your build error, libmupdf.a seems to be a static lib.
• Modified setup.py, then went to pymupdf folder and did: pip install .

[JorjMcKie]

But this is a major change:
Your installation seems to end up with an additional runtime dependency *.so file or am I wrong?
You cannot distribute the result in one wheel.

What I am doing is creating one self-contained binary.

[Mark-Joy]

I have a workaround in my system. To avoid compiling static lib libmupdf-third.a, I simply create a symlink

ln -s libmupdf.so libmupdf-third.so

Now I don't have to modify setup.py.

I want to confirm one thing though. Could you try deleting /usr/lib/libmupdf.so, then do python3 -c "import fitz"
It is to check if fitz is independent of libmupdf.so
For me, doing so I got the below error:

python3 -c "import fitz"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/data/data/com.termux/files/usr/lib/python3.10/site-packages/fitz/__init__.py", line 10, in <module>
    from fitz.fitz import *
  File "/data/data/com.termux/files/usr/lib/python3.10/site-packages/fitz/fitz.py", line 17, in <module>
    from . import _fitz
ImportError: dlopen failed: library "libmupdf.so" not found

[JorjMcKie]

Confirmed:
In my Linux installation (Windows WSL), mupdf is not installed at all and so /usr/lib/ also does not contain libmupdf.so nor any other mupdf component, but pymupdf can be imported just fine.