On 03/21/2014 06:28 PM, Andrew Hughes wrote:
I still think it's better to remove the dlopen/dlsym machinery and use
dynamic linking instead.
I've provided that as an option in IcedTea, but it then means that a different
PCSC
implementation can't be swapped in.
I think you can still use LD_
- Original Message -
> On 02/04/2014 04:48 PM, Andrew Hughes wrote:
>
> > As has already been mentioned on this thread, libraries should have their
> > version increased when the ABI changes. Thus, a libpcsclite.so.2 or later
> > would indicate a different ABI to what the JDK PCSC code w
On 02/04/2014 04:48 PM, Andrew Hughes wrote:
As has already been mentioned on this thread, libraries should have their
version increased when the ABI changes. Thus, a libpcsclite.so.2 or later
would indicate a different ABI to what the JDK PCSC code was written for.
Now, it may be that the code
- Original Message -
>
> Won't this change break systems which don't have libpcsclite.so.1?
> Changes like this need to be thought through. What happens when
> libpcsclite.so.2 comes out?
> As for API changes, shouldn't there be some compatibility requirement on
> APIs as libpcsclite.so ev
On 04/25/2013 12:11 AM, Valerie (Yu-Ching) Peng wrote:
Won't this change break systems which don't have libpcsclite.so.1?
By linking against libpcsclite.so.1 at the ELF level? Yes.
But the dependency is already there, it is just not expressed
explicitly, so it will not be discovered by tools
Hi Valerie,
Thanks for the review!
On Wed, 2013-04-24 at 15:11 -0700, Valerie (Yu-Ching) Peng wrote:
> Won't this change break systems which don't have libpcsclite.so.1?
Yes. However, currently it breaks systems which don't have
libpcsclite.so. [1] would be an example. There is a system property
On Wed, 2013-04-24 at 13:05 +0200, Florian Weimer wrote:
> On 03/01/2013 11:30 AM, Severin Gehwolf wrote:
> > Hi,
> >
> > The bug for this review request is at:
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142
> >
> > In PlatformPCSC.java unversioned native libraries are loaded by def
Won't this change break systems which don't have libpcsclite.so.1?
Changes like this need to be thought through. What happens when
libpcsclite.so.2 comes out?
As for API changes, shouldn't there be some compatibility requirement on
APIs as libpcsclite.so evolves?
Valerie
On 04/24/13 04:05, Fl
On 03/01/2013 11:30 AM, Severin Gehwolf wrote:
Hi,
The bug for this review request is at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142
In PlatformPCSC.java unversioned native libraries are loaded by default
if no system property is specified. This could lead to a JVM crash if
the
On Fri, 2013-03-01 at 11:30 +0100, Severin Gehwolf wrote:
> Hi,
>
> The bug for this review request is at:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142
>
> In PlatformPCSC.java unversioned native libraries are loaded by default
> if no system property is specified. This could lead
Hi,
The bug for this review request is at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142
In PlatformPCSC.java unversioned native libraries are loaded by default
if no system property is specified. This could lead to a JVM crash if
the API of the native library changes, but the Java c
11 matches
Mail list logo
