RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]

Thomas Stuefe stuefe at openjdk.org
Thu Dec 21 08:35:57 UTC 2023


On Thu, 21 Dec 2023 08:16:22 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> What happens if we accidentally attempt to load a "real" static library, which is also named *.a? Would dlopen() then crash? What would happen?

> I don't think the problem is with *.a . They would load as the default behaviour of the dlopen. It is only when the dlopen fails for *.so , we give another chance to check for .a file with the same name.

No, what I meant, and what must be clarified before going forward with this solution, is the following:

- is *every* `*.a` object on AIX loadable with `dlopen`, and will the result be the same as when loading a `*.so` object
- or, if we present arbitrary `*.a` files to dlopen, is there a chance for dlopen to crash or misbehave.

Reason is that I was under the impression that *.a libraries are static libraries and cannot be loaded dynamically. This is what you now try to do.

If we cannot safely answer this question, I would opt for a more narrow solution by hard-wiring known alternative names. So, do the second *.a attempt only for your `ibm_16_am.a` which you know works. That could also be done in a reasonably maintainable manner.

>> Does this really have to be handled in the OpenJDK? What does J9 on AIX do? Could this be done in a simpler way outside OpenJDK, e.g. by providing an *.so variant of the library in question? Where does this library come from?

> I am not sure how J9 handles this. I would have to consult .

J9 is Open Source, can't you just look? :)

> However as per current observation, this issue does not show up on Semuru. This issue is only happening on Adoptium. The team that release these file has always released *.a files which work fine for Semuru.

I don't know what Semuru is. What is the context, is that a different VM? Also OpenJDK? J9 derived?

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

PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1865859345


More information about the serviceability-dev mailing list