Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe 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. >>> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. >> If we try loading a static archive specifically ,how the dlopen would behave >> , that is something probably @JoKern65 can answer ? >> >> >>> > > 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? :) >> >> I did try comparing the file structures, and i do not see a similar file >> structure over there. >> I am unable to find the jvmTiAgent code and also os_aix file. So i am not >> sure which functions over there are doing the same functionality. You have >> any suggestion on how i can check and correlate ? >>> >>> > 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? >> >> >> Semuru is J9 derived. > >> > > > 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. >> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. If we try loading a static >> archive specifically ,how the dlopen would behave , that is something >> probably @JoKern65 can answer ? > > Rather, this is a question you have to ask your collegues at IBM that develop > the AIX libc. > > Since AIX libc is not open source, we cannot look for ourselves, nor can > Joachim (her works at SAP). > >> >> > > > 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? :) >> >> I did try comparing the file structures, and i do not see a
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Tue, 16 Jan 2024 16:12:16 GMT, Martin Doerr wrote: > > I have tried to build jextract > > (https://github.com/openjdk/jextract/tree/jdk22) with LLVM > > (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). > > I noticed that llvm mainly consists of .a files. So, I think we need to > > support that for FFI compatibility with other libraries and open source > > projects. > > Seems like this change is not sufficient for that. `clang` is compiled to > `libclang.a` on AIX, but `libclang.so` on linux. I'm getting "System error: > Exec format error" when trying to load `libclang.a` via > `System.loadLibrary(libName);`. So the question remains: Are .a files really > supposed to be dynamically loadable on AIX? If so, where is that documented? Yes we have rhe case where .a files are dynamically loadable as well on AIX. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1905321150
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Fri, 5 Jan 2024 12:10:59 GMT, Martin Doerr wrote: > I have tried to build jextract > (https://github.com/openjdk/jextract/tree/jdk22) with LLVM > (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). > I noticed that llvm mainly consists of .a files. So, I think we need to > support that for FFI compatibility with other libraries and open source > projects. Seems like this change is not sufficient for that. `clang` is compiled to `libclang.a` on AIX, but `libclang.so` on linux. I'm getting "System error: Exec format error" when trying to load `libclang.a` via `System.loadLibrary(libName);`. So the question remains: Are .a files really supposed to be dynamically loadable on AIX? If so, where is that documented? - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1894060171
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Tue, 16 Jan 2024 08:43:34 GMT, Suchismith Roy wrote: >> src/hotspot/os/aix/os_aix.cpp line 1168: >> >>> 1166: int extension_length = 3; >>> 1167: char* file_path = NEW_C_HEAP_ARRAY(char, buffer_length + >>> extension_length + 1, mtInternal); >>> 1168: strncpy(file_path,filename, buffer_length + 1); >> >> Why not using >> `char* file_path = os::strdup (filename);` >> which would replace lines 1167+1168 >> and use the corresponding >> `os::free (file_path);` >> at the end > > Ok. Any performance advantage to using that ? No, I do not believe that it has performance advantage, but I think it is simpler to understand. - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1453249951
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 13:29:05 GMT, Joachim Kern wrote: >> Suchismith Roy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Spaces fix > > src/hotspot/os/aix/os_aix.cpp line 1168: > >> 1166: int extension_length = 3; >> 1167: char* file_path = NEW_C_HEAP_ARRAY(char, buffer_length + >> extension_length + 1, mtInternal); >> 1168: strncpy(file_path,filename, buffer_length + 1); > > Why not using > `char* file_path = os::strdup (filename);` > which would replace lines 1167+1168 > and use the corresponding > `os::free (file_path);` > at the end Ok. Any performance advantage to using that ? - PR Review Comment: https://git.openjdk.org/jdk/pull/16604#discussion_r1453094259
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 11:16:03 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library ibm_16_am.a shared archive >> file on AIX. >> Hence we are providing a function which will additionally search for .a file >> on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional > commit since the last revision: > > Spaces fix I have tried to build jextract (https://github.com/openjdk/jextract/tree/jdk22) with LLVM (https://github.com/llvm/llvm-project/releases/download/llvmorg-16.0.4/clang+llvm-16.0.4-powerpc64-ibm-aix-7.2.tar.xz). I noticed that llvm mainly consists of .a files. So, I think we need to support that for FFI compatibility with other libraries and open source projects. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1878570142
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe 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. >>> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. >> If we try loading a static archive specifically ,how the dlopen would behave >> , that is something probably @JoKern65 can answer ? >> >> >>> > > 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? :) >> >> I did try comparing the file structures, and i do not see a similar file >> structure over there. >> I am unable to find the jvmTiAgent code and also os_aix file. So i am not >> sure which functions over there are doing the same functionality. You have >> any suggestion on how i can check and correlate ? >>> >>> > 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? >> >> >> Semuru is J9 derived. > >> > > > 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. >> >> In AIX, both static and dynamic libraries have *.a extension. And AIX also >> supports *.so files.Bascially shared objects in AIX have both *.a and *.so >> extension. Hence we need to implement this logic. If we try loading a static >> archive specifically ,how the dlopen would behave , that is something >> probably @JoKern65 can answer ? > > Rather, this is a question you have to ask your collegues at IBM that develop > the AIX libc. > > Since AIX libc is not open source, we cannot look for ourselves, nor can > Joachim (her works at SAP). > >> >> > > > 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? :) >> >> I did try comparing the file structures, and i do not see a
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe 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. > > > > > > In AIX, both static and dynamic libraries have *.a extension. And AIX also > > supports *.so files.Bascially shared objects in AIX have both *.a and *.so > > extension. Hence we need to implement this logic. If we try loading a > > static archive specifically ,how the dlopen would behave , that is > > something probably @JoKern65 can answer ? > > Rather, this is a question you have to ask your collegues at IBM that develop > the AIX libc. > > Since AIX libc is not open source, we cannot look for ourselves, nor can > Joachim (her works at SAP). > > > > > > 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? :) > > > > > > I did try comparing the file structures, and i do not see a similar file > > structure over there. I am unable to find the jvmTiAgent code and also > > os_aix file. So i am not sure which functions over there are doing the same > > functionality. You have any suggestion on how i can check and correlate ? > > Someone must implement LoadLibrary. Try looking for places where dlopen() is > called. > > > > > 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? > > > > > > Semuru is J9 derived. Ok , i was not able to find the right file yet. I will collaborate on this further once i am back from vacation, in January. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1867498645
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 09:37:55 GMT, Suchismith Roy 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. > > In AIX, both static and dynamic libraries have *.a extension. And AIX also > supports *.so files.Bascially shared objects in AIX have both *.a and *.so > extension. Hence we need to implement this logic. If we try loading a static > archive specifically ,how the dlopen would behave , that is something > probably @JoKern65 can answer ? Rather, this is a question you have to ask your collegues at IBM that develop the AIX libc. Since AIX libc is not open source, we cannot look for ourselves, nor can Joachim (her works at SAP). > > > > > 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? :) > > I did try comparing the file structures, and i do not see a similar file > structure over there. I am unable to find the jvmTiAgent code and also os_aix > file. So i am not sure which functions over there are doing the same > functionality. You have any suggestion on how i can check and correlate ? Someone must implement LoadLibrary. Try looking for places where dlopen() is called. > > > > 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? > > Semuru is J9 derived. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1865977132
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 11:16:03 GMT, Suchismith Roy wrote: >> J2SE agent does not start and throws error when it tries to find the shared >> library ibm_16_am. >> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load >> fails.It fails to identify the shared library ibm_16_am.a shared archive >> file on AIX. >> Hence we are providing a function which will additionally search for .a file >> on AIX ,when the search for .so file fails. > > Suchismith Roy has updated the pull request incrementally with one additional > commit since the last revision: > > Spaces fix > > > 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. > In AIX, both static and dynamic libraries have *.a extension. And AIX also supports *.so files.Bascially shared objects in AIX have both *.a and *.so extension. Hence we need to implement this logic. If we try loading a static archive specifically ,how the dlopen would behave , that is something probably @JoKern65 can answer ? > > > 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? :) I did try comparing the file structures, and i do not see a similar file structure over there. I am unable to find the jvmTiAgent code and also os_aix file. So i am not sure which functions over there are doing the same functionality. You have any suggestion on how i can check and correlate ? > > > 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? Semuru is J9 derived. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1865945011
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Thu, 21 Dec 2023 08:16:22 GMT, Suchismith Roy 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
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v7]
On Wed, 20 Dec 2023 14:30:18 GMT, Thomas Stuefe wrote: > Hi, > > some requests and questions: > > * Please modify the JBS title, PR title, and JBS issue text to reflect that > this adds an alternative shared object loading path for shared objects on > AIX. Something like "Allow loading shared objects with .a extension on AIX". > Please describe the new logic in the JBS issue text. > * 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? > * What happens if we accidentally attempt to load a "real" static library, > which is also named *.a? Would dlopen() then crash? What would happen? > * What happens if the original path handed to os::dll_load is already a *.a > file? Should the logic then be reversed? > * We really need regression tests for this. For some of the question I need to consult the folk working on J9. I will answer a few of them if that gives some clarity. > * Please modify the JBS title, PR title, and JBS issue text to reflect that > this adds an alternative shared object loading path for shared objects on > AIX. Something like "Allow loading shared objects with .an extension on AIX". > Please describe the new logic in the JBS issue text. Sure working on it. > * 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 . 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. > * 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. > * What happens if the original path handed to os::dll_load is already a *.a > file? Should the logic then be reversed? I don't think so. We are not modifying the behaviour to handle *.a files here. We are just adding extra checks for *.so files if they fail to load. In the logic , when a load fails, I just check if it is a .so file and perform the loading again. - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1865837275
