[Bug 188369] Review Request: ctapi-cyberjack

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: ctapi-cyberjack


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188369





------- Additional Comments From j.w.r.degoede at hhs.nl  2006-05-06 05:09 EST -------
I've taken a look at part 3 of the docu at:
http://www.teletrust.de/index.php?id=548

It seems that the only relevant part of this pdf for our discussion is in
Appendix A under "identification of CTAPI filenames with a wki" what the
document says here is basicly that dynamicloaded libs implementing the ctapi
should have a name in the following format: ctxxx[yyy] where xxx is a 3 letter
abbreviation of the manufacturer (CTM ID) (the abbreviations are supposed to be
asigned by a national goverment instance)

So that helps a bit, what it says is that the way to install ctapi
implementations for different cardreaders is indeed to use dlopen and name the
implementation .so files different. The 3 letter thingie clearly is because of
the 8 char length limitation dos had, and since there is no list of assigned
abreviations to be found I say we standardize on the name:
libctapi-<manufacturer>.so

But since these libraries are intented to be dlopen-ed and dlopen-ed only, and
as such are unversioned (.so instead of .so.x) I don't believe the belong
directly under %{_libdir} but that they shoud instead be put under say
%{_libdir}/ctapi .

Your story about DT_RPATH and LD_LIBARY_PATH above is about how things work for
regular linked binari%{_libdir}/ctapies (iow not using dlopen). Notice that we
don't need to create subdirs under  for each ctapi-lib instead we could just put
%{_libdir}/ctapi in a file under /etc/ld.so.conf.d . But that would beat the
entire purpose of putting these files in a seperate dir: not poluting the global
library soname namespace with these "plugins" .

Another solution would be to teach the dlopen-ing applications about the new
locations. I've moved ctapi-cyberjack.so* to %{_libdir}/ctapi on my system and
then tried to run cjgeldkarte:
[hans at shalem ~]$ cjgeldkarte
Error loading CT-API library.
[hans at shalem ~]$ cjgeldkarte -l ctapi/libctapi-cyberjack.so
Error loading CT-API library.
[hans at shalem ~]$ cjgeldkarte -l /usr/lib64/ctapi/libctapi-cyberjack.so
Error doing CT_init. (Return code:-1)

As you can see cjgeldkarte can no longer find its default libctapi-cyberjack.so
and passing ctapi/libctapi-cyberjack.so doesn't help either, we need to pass a
full path. Thats unfortunate because I find the full path ugly and it differs
from one arch to the other (usr/lib vs /usr/lib/64) now we can patch the correct
path into the binary during during built but thats not pretty.

The last option is to set DT_RPATH in the elf headers of the binaries using the
plugins to %{_libdir}/ctapi. This is quite easy, just change the "make" line in
the specfile to:
export LD_RUN_PATH=%{_libdir}/ctapi
make 

I must say I prefer this option, because it keeps the unversioned ctapi
libraries out of the regular soname namespace.

I'll open a bug against openct which currently also installs an unversioned .so
file in %{_libdir} for the ctapi.

Hopefully with the input of the openct maintainer we can choose one of the 3
choises which I see we have:
1) drop unversioned .so 's only intended for dlopen in %{_libdir}
2) put them in %{_libdir}/ctapi and code full path's to them (and users
   who want to use a different then the defualtlib also must specify the full 
   path).
3) put them in %{_libdir}/ctapi and set rpath to %{_libdir}/ctapi for binaries
   using the ctapi

1 and 3 are realistic options in my vision 2 is not.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.