| Summary: | app-arch/unrar: unrar binary should link against the libunrar shared library | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Josh Jackson <pturing> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | QA | CC: | alastairmurray, kovid, mk, nikoli, rhill, timmy |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=622854 https://bugs.gentoo.org/show_bug.cgi?id=622856 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Patch to build -fPIC shared library and install headers.
Alternative one |
||
|
Description
Josh Jackson
2007-05-07 05:15:01 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 > 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 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.
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
Of course this 'hack' won't still link the unrar binary against the just built shared library... Do we want that? 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) Calibre will not unrar without this library. Comment on attachment 222383 [details, diff]
Alternative one
Obsoleted current attachment(s) and will attach new one in a moment
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. +*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 eheh, now it's crashing, reopening again (sorry for spam) 4.1.4-r1 crashes media-gfx/mcomix when opening cbr archives. Can you put 4.1.4 back? (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. It doesn't use the executable when the shared library is available. 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. 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.. See bug #401355. (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". 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. An USE flag is a bad idea in this case. Even if upstream has no idea how this works, we generally do. (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. We build libunrar now with unrar but the binary unrar still has different ifdef's enabled than the libunrar this package ships. Since this isn't exactly a 'fix' but it resolves the goal of the bug which was to have a libunrar available for other packages, I'm closing this. I'm not interested at all in patching the unrar binary which may break packages I and others maintain. I have also linked 2 calibre bugs regarding adding rar support there. The situation might be a little different now that calibre is on python3. (More like a WONTFIX, I think, or a WORKSFORME.) |
