Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 177402 - app-arch/unrar: unrar binary should link against the libunrar shared library
Summary: app-arch/unrar: unrar binary should link against the libunrar shared library
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All All
: Normal QA with 3 votes (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-07 05:15 UTC by Josh Jackson
Modified: 2014-04-16 23:07 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to build -fPIC shared library and install headers. (unrar-3.9.9-shared_library.patch,572 bytes, patch)
2010-03-06 23:45 UTC, Samuli Suominen
Details | Diff
Alternative one (unrar-3.9.9-shared_library.patch,1022 bytes, patch)
2010-03-07 00:04 UTC, Samuli Suominen
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Jackson 2007-05-07 05:15:01 UTC
I'm considering packaging libprs500 ( https://libprs500.kovidgoyal.net/ )
It has an optional dependency of libunrar.so
This can be built from the sources of app-arch/unrar by running:
make lib

but the current ebuild does not build this target

possibly this could be setup as a local use flag or separate ebuild, if not everyone wants to have libunrar.so

Reproducible: Always

Steps to Reproduce:
1. emerge unrar
2. equery files unrar

Actual Results:  
[ Searching for packages matching unrar... ]
* Contents of app-arch/unrar-3.7.5:
/usr
/usr/bin
/usr/bin/unrar
/usr/share
/usr/share/doc
/usr/share/doc/unrar-3.7.5
/usr/share/doc/unrar-3.7.5/readme.txt.bz2


Expected Results:  
[ Searching for packages matching unrar... ]
* Contents of app-arch/unrar-3.7.5:
/usr
/usr/bin
/usr/bin/unrar
/usr/lib/libunrar.so
/usr/share
/usr/share/doc
/usr/share/doc/unrar-3.7.5
/usr/share/doc/unrar-3.7.5/readme.txt.bz2
Comment 1 SpanKY gentoo-dev 2007-05-07 10:14:58 UTC
the makefile will need to be reworked as it does not generate a PIC .so

also, a library is useless without a header and i dont see any particular header that would expose a proper API
Comment 2 Josh Jackson 2007-05-07 16:00:24 UTC
> also, a library is useless without a header and i dont see any particular
> header that would expose a proper API
 
Oh right. Wasn't thinking about that since you don't need the header at build time for the other package, which is written in python.

It looks like the relevant file is dll.hpp

The freebsd guys are putting this header in /usr/include/libunrar3/
http://cvsup.pt.freebsd.org/cgi-bin/cvsweb/cvsweb.cgi/ports/archivers/libunrar/Makefile?rev=1.5
Comment 3 Samuli Suominen gentoo-dev 2010-03-06 23:45:46 UTC
Created attachment 222373 [details, diff]
Patch to build -fPIC shared library and install headers.

Install dll.hpp to same location as FreeBSD (checked Ports directory today).
Add -fPIC to CPPFLAGS (a bit wrong place, maybe, but it's already there and empty)
and sed -Wl,-soname in.
Comment 4 Samuli Suominen gentoo-dev 2010-03-07 00:04:54 UTC
Created attachment 222383 [details, diff]
Alternative one

This would add USE="lib" since most people don't need it, and build the objects twice, once -fPIC and once without reducing the overhead
Comment 5 Samuli Suominen gentoo-dev 2010-03-07 00:08:46 UTC
Of course this 'hack' won't still link the unrar binary against the just built shared library...

Do we want that?
Comment 6 SpanKY gentoo-dev 2010-03-09 17:30:05 UTC
i'm fine with building just libunrar.so, so no need to do pic/non-pic for .so/.a

i would want the unrar binary to link against libunrar.so though, and to not force -fPIC on to all objects (using CPPFLAGS sounds like it would do just that)
Comment 7 Jayson 2010-05-04 04:07:07 UTC
Calibre will not unrar without this library.
Comment 8 Samuli Suominen gentoo-dev 2012-01-18 13:43:39 UTC
Comment on attachment 222383 [details, diff]
Alternative one

Obsoleted current attachment(s) and will attach new one in a moment
Comment 9 Samuli Suominen gentoo-dev 2012-01-18 21:58:20 UTC
fixed in 4.1.4-r1(In reply to comment #6)
> i'm fine with building just libunrar.so, so no need to do pic/non-pic for
> .so/.a
> 
> i would want the unrar binary to link against libunrar.so though, and to not
> force -fPIC on to all objects (using CPPFLAGS sounds like it would do just
> that)

4.1.4-r1 now builds libunrar as shared library but I couldn't make the unrar binary link against the shared library for some reason.
keeping open and working on it.
Comment 10 Samuli Suominen gentoo-dev 2012-01-23 23:48:48 UTC
+*unrar-4.1.4-r2 (23 Jan 2012)
+
+  23 Jan 2012; Samuli Suominen <ssuominen@gentoo.org> +unrar-4.1.4-r2.ebuild:
+  Link "unrar" executable against the shared libunrar wrt #177402
Comment 11 Samuli Suominen gentoo-dev 2012-01-23 23:51:56 UTC
eheh, now it's crashing, reopening again (sorry for spam)
Comment 12 Ryan Hill (RETIRED) gentoo-dev 2012-01-28 17:58:27 UTC
4.1.4-r1 crashes media-gfx/mcomix when opening cbr archives.  Can you put 4.1.4 back?
Comment 13 Samuli Suominen gentoo-dev 2012-01-28 19:55:59 UTC
(In reply to comment #12)
> 4.1.4-r1 crashes media-gfx/mcomix when opening cbr archives.  Can you put 4.1.4
> back?

4.1.4-r1 builds the unrar executable just like any other older version, so putting 4.1.4 back doesn't make sense, and the issue is likely unrelated to this bug.
Comment 14 Ryan Hill (RETIRED) gentoo-dev 2012-01-29 00:26:05 UTC
It doesn't use the executable when the shared library is available.
Comment 15 Ryan Hill (RETIRED) gentoo-dev 2012-01-29 03:07:17 UTC
In any case it shows that the lib itself is broken somehow and we shouldn't install it until we fix it.  Let's restore 4.1.4 and mask -r1 until then.
Comment 16 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-01-29 16:02:36 UTC
Can you provide a bit more detail on how mcomix crashes? Because if it's using dlopen() it might as well be mcomix being badly designed, rather than the library itself broken..
Comment 17 Ryan Hill (RETIRED) gentoo-dev 2012-01-29 17:15:03 UTC
See bug #401355.
Comment 18 Maxim Kammerer 2012-03-06 12:51:35 UTC
(In reply to comment #9)
> I couldn't make the unrar binary link against the shared library for some reason. keeping open and working on it.

The source files have different #ifdefs activated, depending on whether they are compiled for the binary or for the library. E.g., RARDLL triggers SLEEP, which disables mprintf() in consio.*.

It seems to me that linking the unrar binary against its corresponding shared library is explicitly unsupported by upstream. So perhaps USE=lib should return. See, e.g., dll.def (apparently, the only symbols exported by the library in Windows):

EXPORTS
  RAROpenArchive
  RAROpenArchiveEx
  RARCloseArchive
  RARReadHeader
  RARReadHeaderEx
  RARProcessFile
  RARSetCallback
  RARSetChangeVolProc
  RARSetProcessDataProc
  RARSetPassword
  RARGetDllVersion

If anything, symbols visibility in the Linux library should be fixed accordingly -- see "Export Control" in Ulrich Drepper's "How To Write Shared Libraries".
Comment 19 Maxim Kammerer 2012-07-09 10:06:09 UTC
I contacted upstream with a request for comment about this issue, and received the following reply from Eugene Roshal:

-----
UnRAR is not designed to use unrar.dll or libunrar.

In fact, we do not maintain libunrar officially.
Main purpose of our unrarsrc package is building the portable
UnRAR tool. Since we use the same code base for unrar.dll,
as a side effect it is possible to build Windows unrar.dll
from same code.

But we never built the library for Unix systems ourselves.
It was done by users and users sent us updated makefile
for this purpose. I did not test these modifications
and I have very little experience in Unix libraries.
-----

To me it looks like USE=lib is the optimal solution.
Comment 20 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-09 10:59:30 UTC
An USE flag is a bad idea in this case. Even if upstream has no idea how this works, we generally do.
Comment 21 Maxim Kammerer 2012-07-09 11:29:20 UTC
(In reply to comment #20)
> Even if upstream has no idea how this works, we generally do.

It doesn't matter in this case -- see comment #18:

> The source files have different #ifdefs activated, depending on whether they are compiled for the binary or for the library.

The problem is not that upstream is unfamiliar with Unix libraries, the problem is that the library is a later addition, and has differing functionality.