Bug 407807 – app-text/mupdf: Missing shared libraries

• Product: Gentoo Linux
• Status: RESOLVED TEST-REQUEST

[Description Samuli Suominen (RETIRED) 2012-03-11 15:17:47 UTC]

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

[Comment 1 Samuli Suominen (RETIRED) 2012-03-11 15:20:34 UTC]

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

[Comment 2 Samuli Suominen (RETIRED) 2012-03-30 20:21:50 UTC]

Any chance for a new snapshot? Assuming this got fixed by upstream since it was closed as such.

[Comment 3 Michael Weber (RETIRED) 2012-04-07 18:32:23 UTC]

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.

[Comment 4 Samuli Suominen (RETIRED) 2012-09-07 09:41:44 UTC]

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

[Comment 5 Franz Trischberger 2012-09-12 08:49:14 UTC]

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.

[Comment 6 Michael Weber (RETIRED) 2013-06-07 22:52:27 UTC]

+  07 Jun 2013; Michael Weber <[e-mail]>
+  -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 7 Michael Weber (RETIRED) 2013-06-07 22:58:23 UTC]

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].