RFR: 8009550: PlatformPCSC should load versioned so [v2]

[Andrew John Hughes]

On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Changes look fine. I submitted a mach5 test job just in case. Will approve once the test job passes. BTW, I added a noreg-other label since there is no regression test for this change.
>> 
>> Thanks. Yes, I don't see how we can have a regression test for this one. My own testing was manual and involved moving the system library around as root...
>
>> > Hi @gnu-andrew,
>> > in your last example, why does it look for both arm and x64 packages? And why for kFreeBsd? I see you have both hardcoded, why?
>> > I would expect it only to attempt and pick up the architecture and OS the VM was built for.
>> 
>> Good question.
>> 
>> Because they don't fit the template `$ARCH-linux-gnu/libpcsclite.so` which would expand to `arm-linux-gnu/libpcsclite.so`.
>> 
>> I don't know of a way off-hand to get the ABI or the kernel in use (`kfreebsd` is not a BSD variant, but the usual GNU userland paired with the FreeBSD kernel rather than Linux). The [Wikipedia page](https://en.wikipedia.org/wiki/Debian#Derivatives_and_flavors) actually says it's now discontinued, so maybe we can just drop that one. It probably shows how long ago I [originally wrote and tested these paths](https://icedtea.wildebeest.org/hg/release/icedtea7-forest-2.6/jdk/rev/ae5765c7b8e2)... :)
>> 
>> In short, that was my lazy option for catching those cases that won't fit the common one. I'm open to suggestions. We could skip any template with `'arm'` in, I guess, if the architecture doesn't match. It is worth noting though, that this file is already common to all the UNIX platforms and doesn't do any OS checks, despite the last check being a MacOS framework. That also presumably means MacOS doesn't have any of the `/usr` libraries in turn .
> 
> Yes, that's a bit tricky. I was concerned about the JVM picking up the wrong library on a mulitarch system, since having multiple  of these directories is the point of multiarch.
> 
> But maybe its fine. The difference between the arm variants is that the float mode (soft vs hard) and I believe the former should always work, so if we accidentally pick it up, it should be no problem.
> 
> The kfreebsd one I'd just drop.

@tstuefe if you're happy with the minor change I added, I'll push.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1706883089