Bug 910107 - fail to load PC/SC library
fail to load PC/SC library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.7.0-openjdk (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Severin Gehwolf
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-11 15:31 EST by Aleksandar Kostadinov
Modified: 2014-01-30 12:49 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-30 12:49:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksandar Kostadinov 2013-02-11 15:31:54 EST
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/
Comment 1 Severin Gehwolf 2013-02-12 05:04:02 EST
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.
Comment 2 Aleksandar Kostadinov 2013-02-12 12:25:52 EST
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
Comment 3 Severin Gehwolf 2013-02-13 04:16:44 EST
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
Comment 4 Kalev Lember 2013-02-13 07:25:36 EST
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.
Comment 5 Severin Gehwolf 2013-02-13 10:20:28 EST
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?
Comment 6 Ludovic Rousseau 2013-02-14 03:31:27 EST
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.
Comment 7 Deepak Bhole 2013-02-21 16:24:22 EST
(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.
Comment 8 Severin Gehwolf 2013-03-01 05:33:42 EST
I've proposed to fix this in PlatformPCSC.java upstream.

http://mail.openjdk.java.net/pipermail/security-dev/2013-March/006853.html
Comment 9 Fedora End Of Life 2013-12-21 10:22:09 EST
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.
Comment 10 Andrew John Hughes 2014-01-29 10:41:01 EST
Included in 2.4.5:

http://blog.fuseyism.com/index.php/2014/01/29/icedtea-2-4-5-released/

Note You need to log in before you can comment on or make changes to this bug.