Openjdk is failing to load libpcsclite in fedora 18. For example running gpj [1] results in: java.io.IOException: No PC/SC library found on this system To workaround: sudo ln -s /usr/lib64/libpcsclite.so.1 /usr/lib64/libpcsclite.so [1] http://sourceforge.net/projects/gpj/
Aleksandar, PlatformPCSC.java tries to load two known locations for PC/SC libraries. These are: /usr/lib{,64}/libpcsclite.so /usr/local/lib{,64}/libpcsclite.so If the PC/SC library is at any other location it has to be specified via the "sun.security.smartcardio.library" system property. It cannot try all possible file names. Please use something like the following for running gpj: java -Dsun.security.smartcardio.library=/usr/lib64/libpcsclite.so.1.0.0 -jar gpj.jar I'm closing this as not-a-bug. Maybe, you could make gpj upstream aware of this. Alternatively, you could ask pcsc-lite maintainers to provide the symlink you mention above in the packaged version of pcsc-lite in Fedora.
Severin, is not PlatformPCSC.java part of openjdk? How could it be a bug in gpj then? The bug I see here is that PlatformPCSC cannot find the pcsc lib by default on fedora 18. Can that not be a bug? My understanding is that this can affect other programs, not only gpj. Now you, as more knowledgeable than me in this matters could consider it a bug with pcsc-lite, not openjdk. In such case, please change component to pcsc-lite, that's fine with me. But just closing the issue looks wrong to me. Please let me know if I'm missing something and please change component as appropriately, because you can better explain the pcsc-lite maintainer why is it a bug in pcsc-lite instead of openjdk. Thank you, Aleksandar
Hi Aleksandar, Sorry for the confusion. (In reply to comment #2) > Severin, is not PlatformPCSC.java part of openjdk? Yes. > How could it be a bug in > gpj then? I didn't say that. What I meant is that it would be helpful to have something in gpj docs making users aware of the sun.security.smartcardio.library property if this "No PC/SC library found on this system" error happens. > The bug I see here is that PlatformPCSC cannot find the pcsc lib by default > on fedora 18. Can that not be a bug? My understanding is that this can > affect other programs, not only gpj. Ok. If anything, this is a bug in pcsc-lite, which fails to ship the following symlink: /usr/lib64/libpcsclite.so => /usr/lib64/libpcsclite.so.1.0.0 > Now you, as more knowledgeable than me in this matters could consider it a > bug with pcsc-lite, not openjdk. In such case, please change component to > pcsc-lite, that's fine with me. But just closing the issue looks wrong to me. I did close this issue as not a bug as PlatfomPCSC looks up some "standard" locations (as noted above) and as a last resort uses the sun.security.smartcardio.library property in order to find the pcsclite so. I don't think it's feasible for openjdk to try more than these two "standard" locations before requiring user intervention as to where the library actually is. > Please let me know if I'm missing something and please change component as > appropriately, because you can better explain the pcsc-lite maintainer why > is it a bug in pcsc-lite instead of openjdk. Reassigning component to pcsc-lite. Let me know if you've got more questions. Thanks, Severin
With my pcsc-lite packager hat on: pcsc-lite in Fedora is packaged as per upstream recommendation, so that the .so symlink is in the -devel package. Please patch java to dlopen() libpcsclite.so.1 directly, instead of going through the .so symlink. pcsc-lite is packaged the same way in Debian (libpcsclite.so is in the -dev package) and I assume in other larger distros as well, so the patch should be nicely upstreamable. Reassigning to openjdk.
I can confirm that gpj works fine on fedora 18 with pcsc-lite-devel installed (no property required): $ java -jar gpj.jar Alexsandar, would this be acceptable? One can set the location of libpcsclite via a Java system property so that it opens that library directly. The following works: $ java -Dsun.security.smartcardio.library=/usr/lib64/libpcsclite.so.1.0.0 -jar gpj.jar > Please patch java to dlopen() libpcsclite.so.1 directly, FWIW, libpcsclite.so.1 is a symlink to libpcsclite.so.1.0.0. With all that said, it's not difficult to patch openjdk to look for libpcsclite.so.1 instead of/in addition to other locations. Since there is already the system property for this case, it doesn't make much sense to me. Upstream openjdk would likely not accept such a patch since *NIX'es are target platforms as well. Deepak, is this something we should consider doing for Fedora?
I am the pcsc-lite maintainer. Using libpcsclite.so instead of libpcsclite.so.1 is a bug. If/when the PC/SC API change libpcsclite.so will link to libpcsclite.so.2 and Java may crash by using a non corresponding API. It is a bug of the Java VM and should be fixed upstream.
(In reply to comment #5) > With all that said, it's not difficult to patch openjdk to look for > libpcsclite.so.1 instead of/in addition to other locations. Since there is > already the system property for this case, it doesn't make much sense to me. > Upstream openjdk would likely not accept such a patch since *NIX'es are > target platforms as well. Deepak, is this something we should consider doing > for Fedora? Based on comment #6, we should propose this upstream IMO.
I've proposed to fix this in PlatformPCSC.java upstream. http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006853.html
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Included in 2.4.5: http://blog.fuseyism.com/index.php/2014/01/29/icedtea-2-4-5-released/