[Bug 188369] Review Request: ctapi-cyberjack
by Red Hat Bugzilla
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(a)hhs.nl 2006-05-06 06:37 EST -------
The 4th alternative sounds like the best one to me. In this case I don't think
we need to standardise the .so filenames, since they are already under
%{_libdir}/ctapi, making clear what they are and giving apps a unique way to
enumerate all ctapi implementations available (all .so files under %{_libdir}/ctapi)
So I say lets go with the 4th approach:
-ctapi implementing libs go under %{_libdir}/ctapi
-%{_libdir}/ctapi is owned by ctapi-common
-ctapi-common drops a (64 and 32bit?) file under /etc/ld.so.conf.d
-ctapi implementing libs must depend on ctapi-common(.arch?)
Who wants to create the ctapi-common package?
We should also think about a ctapi-devel package containing a unified ctapi.h
ctbcs.h and maybe manpages (from the towitoko ctapi upstream)
--
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.
18 years
[Bug 188369] Review Request: ctapi-cyberjack
by Red Hat Bugzilla
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 ville.skytta(a)iki.fi 2006-05-06 06:17 EST -------
I agree with your vision wrt. 1) and 2), but I think 3) represents a too FE
centric world view which will cause some pain for 3rd party non-FE apps that
rightfully (per the spec) assume that they can just dlopen() the module.
1) is not too nice, agreed, but a fourth alternative would be to ship let's say
a ctapi-common package which drops a /etc/ld.so.conf.d/ctapi.conf snippet which
adds %{_libdir}/ctapi to the linker's load path, as well as include a README in
the package that describes the install location and naming conventions for FE
CT-API modules.
There is also a slight issue wrt. the libctapi-<implementation>.so scheme
because in some cases, for example openct and (I guess) towitoko, it would
differ from upstream module names. I think we should either stick with upstream
naming or create compatibility symlinks.
--
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.
18 years
[Bug 188369] Review Request: ctapi-cyberjack
by Red Hat Bugzilla
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(a)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@shalem ~]$ cjgeldkarte
Error loading CT-API library.
[hans@shalem ~]$ cjgeldkarte -l ctapi/libctapi-cyberjack.so
Error loading CT-API library.
[hans@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.
18 years