Bug 190903 - Unversioned .so installed in %{_libdir}
Unversioned .so installed in %{_libdir}
Product: Fedora
Classification: Fedora
Component: openct (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
: 196441 (view as bug list)
Depends On:
Blocks: 188369
  Show dependency treegraph
Reported: 2006-05-06 05:21 EDT by Hans de Goede
Modified: 2010-04-13 11:30 EDT (History)
4 users (show)

See Also:
Fixed In Version: 0.6.7-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-07 09:55:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2006-05-06 05:21:32 EDT
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

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:

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

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:
Comment 1 Ville Skyttä 2006-05-06 06:04:23 EDT
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 06:32:49 EDT
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 09:55:58 EDT
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 08:16:21 EDT
*** Bug 196441 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Zabolotny 2010-04-13 11:16:06 EDT
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 11:30:58 EDT
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.