I would need a shared libraries out of libmuxps, libmupdf and libfitz for building zathura-pdf-mupdf plug-in for bug 407805. A hack would be to compile the current static archives with -fPIC but this is not the Gentoo-way as per: http://www.gentoo.org/proj/en/hardened/pic-guide.xml
Just to demonstrate the problem: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../lib64/libmupdf.a(pdf_page.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/../../../../lib64/libmupdf.a: could not read symbols: Bad value
Any chance for a new snapshot? Assuming this got fixed by upstream since it was closed as such.
Hello Samuli, lets start all over again. 1) I agree with your wish to have an .so library to support zathura etc. 2) I disagree on your comment on bug 407805, "our [...] package is broken and doesn't include shared libraries". It's an deficiency on mupdf itself, not providing any build target for an .so. Other arches like Debian ([1]) don't have any .so either. I've closed this reso/upstream in error, trying to say "it's an upstream issue". To get this fixed, I would suggest either you provide an buildsystem patch to include and send upstream, or I contact upstream and ask for it. Sorry for the bugspam. Michael [1] http://packages.debian.org/wheezy/amd64/mupdf/filelist (In reply to comment #0) > Created attachment 304911 [details] > zathura-pdf-mupdf-0.1.0.ebuild > > New plug-in for app-text/zathura. > > Attaching initial untested ebuild because our app-text/mupdf package is > broken and doesn't include shared libraries to link against.
Upstream bug and patch can be found here: http://bugs.gentoo.org/show_bug.cgi?id=407805#c1 http://bugs.ghostscript.com/show_bug.cgi?id=693009
Created attachment 323588 [details, diff] mupdf-1.1_shared_lib.patch similar patch for mupdf-1.1. I also found this upstream bugreport: http://bugs.ghostscript.com/show_bug.cgi?id=691887 They clearly state that they won't support shared libs. So if Gentoo wants to have shared mupdf-libraries it needs to patch mupdf.
+ 07 Jun 2013; Michael Weber <xmw@gentoo.org> + -files/mupdf-1.0-buildsystem.patch, metadata.xml, mupdf-1.0.ebuild, + mupdf-1.1.ebuild, mupdf-1.1_p20121127.ebuild, mupdf-1.2.ebuild, + mupdf-9999.ebuild: + Switch to shared libs and binaries (USE=static static-libs, bug 407807), + Desktop integration patch, advanced buildsystem patch for 1.0
Comment on attachment 323588 [details, diff] mupdf-1.1_shared_lib.patch I did an different approach by duplicating the source trees to ${S} and ${S}-static (if needed). I redefine the FITZ_LIB name, redefine the FITZ_LIB rule and LINK_CMD. the -fpic is injected via XCFLAGS, just for the shared tree. The static tree got some modification to link the binaries against static libs. Last missing dep is openjpeg[static-libs].
