ebook-convert epub to pdf RuntimeError

[theducks]

Originally Posted by xiatian

Thanks, but I prefer the official AMD64 Linux binary release from GitHub—it’s the cleanest way to install calibre in my complex Debian 12 environment. Anyway, I’ve already found a workaround as I mentioned.

Distros are known to tamper with pieces that calibre depends upon. That is why the OFFICIAL commandline makes sure it has what calibre was designed with.

You have been advised. Refusal to try is wasting all our time.

[xiatian]

Originally Posted by kovidgoyal

https://github.com/kovidgoyal/calibr...a9f3a5e1120195

Thanks for your work! But tested the new preload_libxml2() fix in bypy/linux/site.py — it doesn't fully solve the problem, still get the same RuntimeError. I'm not sure if it's worth more work since I've already worked around it on my end with QTWEBENGINE_CHROMIUM_FLAGS="--disable-gpu --disable-software-rasterizer".
However, if it is worth to devote more, here is the LD_DEBUG process:

The preload does work as intended — libxml2.so.16 and lxml.etree.so
get loaded early, before anything else:

find library=libxml2.so.16 [0]; searching
trying file=/root/calibre/lib/libxml2.so.16
...
calling init: /root/calibre/lib/calibre-extensions/lxml.etree.so

But later in the same process, once QtWebEngine reaches its EGL/Mesa
fallback, libxml2.so.2 still gets pulled in and loaded on top of it:

calling init: /lib/x86_64-linux-gnu/libEGL_mesa.so.0
find library=libxml2.so.2 [0]; searching
trying file=/root/calibre/lib/libxml2.so.2
trying file=/lib/x86_64-linux-gnu/libxml2.so.2
calling init: libicudata.so.72 / libpciaccess.so.0 / libxml2.so.2
calling init: libLLVM-15.so.1
calling init: /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
calling init: html5_parser.html_parser.so
RuntimeError: html5-parser and lxml are using different versions
of libxml2 ... html5-parser: (2, 9, 14) != lxml: (2, 15, 3)

So preloading libxml2.so.16 first doesn't prevent libxml2.so.2 from
also being loaded afterward — they're different SONAMEs, so the
dynamic linker treats them as two separate libraries and happily
loads both into the same process rather than deduping. Whatever
symbol html5-parser's version check reads still seems to resolve to
the later-loaded one.

Preloading the correct version doesn't seem sufficient on its own —
the Mesa software-rasterizer fallback (swrast_dri.so, pulling in the
system's libxml2.so.2) still needs to either be prevented from loading
at all, or html5-parser's version check needs to explicitly bind to
the calibre-bundled library instance rather than relying on implicit
symbol resolution.

[kovidgoyal]

Hmm well that should be fixed by pre loading html5_parser as well.

[JSWolf]

Originally Posted by xiatian

Thanks, but I prefer the official AMD64 Linux binary release from GitHub—it’s the cleanest way to install calibre in my complex Debian 12 environment. Anyway, I’ve already found a workaround as I mentioned.

But you should not have had to do that had you installed the official release. Besides, there's now a plugin you can use to update calibre for you. That way you’d get the official version without any extra gotchas

It's called Calibre Auto-Updater.

[PeterT]

I'm as usual baffled and confused. The OP states they install Calibre using the official release of the AMD64 build from GitHub. No where do they mention installing from a distributions repository.