Bug 190903 - Unversioned .so installed in %{_libdir}
Summary: Unversioned .so installed in %{_libdir}
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openct
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ville Skyttä
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 196441 (view as bug list)
Depends On:
Blocks: 188369
TreeView+ depends on / blocked
 
Reported: 2006-05-06 09:21 UTC by Hans de Goede
Modified: 2010-04-13 15:30 UTC (History)
4 users (show)

Fixed In Version: 0.6.7-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-05-07 13:55:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Hans de Goede 2006-05-06 09:21:32 UTC
openct installs a wrapper lib which makes it possible to talk to openct
supported readers through the ctapi: %{_libdir}/libopenctapi.so.

Part of the ctapi "standard" is that the ctapi implementing lib gets dlopen'ed
since there can be different ctapi libs for different readers installed on the
system.

Since the library only gets dlopen-ed and never linked to, not being versioned
isn't really a problem (IMHO). But since it isn't versioned and only dlopened it
doesn't belong directly under %{_libdir} (again IMHO). I would like to suggets
to instead put it under %{_libdir}/ctapi and maybe at the same time rename it
to: libctapi-openct.so .

The reason for me looking into this ctapi stuff is the review request of
ctapi-cyberjack, which out of the box installed an unversioned .so file too:
%{_libdir}/libctapi-cyberjack.so

My main purpose of filing this bug is to come to some sort of standard way for
installing ctapi libs (dlopen-only so plugins?) Putting the .so files in
%{_libdir}/ctapi instead of just %{_libdir} does create some troubles for the
applications doing the dlopening, this can be fixed by either coding fullpaths
into the apllication or by setting rpath during linking of these applications to
%{_libdir}/ctapi.

Anyways for the full story see the review request, bug 188369 . Your input on
this is much appreciated. You may want to jump directly to comment 40:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369#c40

Comment 1 Ville Skyttä 2006-05-06 10:04:23 UTC
I'm following bug 188369 and will comment there to keep most of the discussion
in one place.

Comment 2 Ville Skyttä 2006-05-06 10:32:49 UTC
By the way, a new openct is out, no changes yet wrt. this in the package pushed
to devel.  I'm holding updating FE5 until this discussion reaches a conclusion.

Comment 3 Ville Skyttä 2006-05-07 13:55:58 UTC
Fixed in 0.6.7-2.fc6, FC-5 will follow later when ctapi-common is available for it.

Comment 4 Frank Büttner 2006-06-23 12:16:21 UTC
*** Bug 196441 has been marked as a duplicate of this bug. ***

Comment 5 Andrew Zabolotny 2010-04-13 15:16:06 UTC
Actually libopenctapi.so is now dynamicaly linked by another shared lib:

# ldd /usr/lib/pcsc/drivers/openct-ifd.bundle/Contents/Linux/openct-ifd.so
	linux-gate.so.1 =>  (0x00f24000)
	libpcsclite.so.1 => /usr/lib/libpcsclite.so.1 (0x00bd8000)
	libopenctapi.so => not found
	libpthread.so.0 => /lib/libpthread.so.0 (0x00110000)
	libc.so.6 => /lib/libc.so.6 (0x00619000)
	libdl.so.2 => /lib/libdl.so.2 (0x00800000)
	/lib/ld-linux.so.2 (0x005f8000)

So, either a respective file has to be installed into /etc/ld.so.conf.d/, or the file has to be moved back into lib/.

Comment 6 Ville Skyttä 2010-04-13 15:30:58 UTC
I no longer maintain or use the openct package, I suggest filing a new bug so the current maintainer hears about it.


Note You need to log in before you can comment on or make changes to this bug.