On Wed, 30 Aug 2023 06:25:44 GMT, Thomas Stuefe <stu...@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 can I get a final ok on this one to push? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15409#issuecomment-1781228578
