> This was intentionally not supported by the upstream. The think fitz is > still immature and should not be exposed nor dynamically linked. You > should try to talk to upstream :)
I believe this is outside the scope of this thread. I understand this is somewhat an experimental API, but in any case people will start using (even as .a) so any ABI breakage will be an issue (the fact that it is shipped as .so is irrelevant). The fact that it is shipped as .so will be a tremendous help to security. I will need to double check but the debian handbook specify that you should ship a .so by default, unless there is a good reason not to. In any case the .a as compiled is totally useless on amd64; eg: x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -fPIC -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-2.7/fitz/fitz_wrap.o -lmupdf -lcrypto -ljbig2dec -lopenjp2 -ljpeg -lfreetype -lmupdfthird -o /tmp/p/PyMuPDF-1.9.2/.pybuild/pythonX.Y_2.7/build/fitz/_fitz.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libmupdf.a(draw-device.o): relocation R_X86_64_PC32 against symbol `fz_empty_irect' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status I'll file another bug but those two will be closely linked. Thanks for packaging mupdf !
