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@xxxxxx 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review