On Wed, 22 Nov 2023 06:50:07 GMT, Jorn Vernee wrote:
>> suchismith1993 has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Fix Typos
>> - Remove unnecessary includes
>
> Note that on Windows we also have a lookup mechanism on the Java sid
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 17:54:08 GMT, suchismith1993 wrote:
>> src/java.base/aix/native/libsyslookup/syslookup.c line 30:
>>
>>> 28: #include
>>> 29: #include
>>> 30: #include
>>
>> Are string.h and stdlib.h needed? I can't see them in the comments below.
>
> string.h is needed for strlen. Let m
On Tue, 21 Nov 2023 17:49:43 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 17:50:04 GMT, Martin Doerr wrote:
>> suchismith1993 has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Comments
>> - Change comments
>
> src/java.base/aix/native/libsyslookup/syslookup.c line 30:
>
>> 28: #include
>
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
On Tue, 21 Nov 2023 11:52:23 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
On Tue, 21 Nov 2023 11:21:40 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a list of symbols to allow math library symbols
> to be ac
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a
On Fri, 17 Nov 2023 15:39:49 GMT, Magnus Ihse Bursie wrote:
> The syslookup.c solution for Windows looks interesting. While it is still a
> hard-coded list, at least you will get compile time errors if the include
> file changes to mismatch with the symbols...
I don't think AIX has a way to do
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a
On Fri, 17 Nov 2023 13:02:22 GMT, Martin Doerr wrote:
> > And I still don't understand if this is the list of symbols that are
> > required by our tests, or the complete list of symbols that FFI
> > `defaultLookup` returns to user applications. If it is the latter, then
> > this is sort-of oka
On Fri, 17 Nov 2023 13:02:22 GMT, Martin Doerr wrote:
> My understanding is that a lot of symbols can be found out of the box because
> they are in dynamically linked libraries. Only some libraries are special on
> AIX which don't support dynamic linking and we need this workaround for them.
T
On Fri, 17 Nov 2023 12:45:32 GMT, suchismith1993 wrote:
> And I still don't understand if this is the list of symbols that are required
> by our tests, or the complete list of symbols that FFI `defaultLookup`
> returns to user applications. If it is the latter, then this is sort-of okay
> as a
On Fri, 17 Nov 2023 12:06:48 GMT, Martin Doerr wrote:
>>> > There is not generic way of generating this. It needs a manual
>>> > intervention and symbols are to be added on a need basis in future. Looks
>>> > like a list to be maintained. I had tried adding comments to explain the
>>> > list,
On Fri, 17 Nov 2023 12:06:48 GMT, Martin Doerr wrote:
>>> > There is not generic way of generating this. It needs a manual
>>> > intervention and symbols are to be added on a need basis in future. Looks
>>> > like a list to be maintained. I had tried adding comments to explain the
>>> > list,
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
make/data/hotspot-symbols/symbols-aix-foreign line 1:
> 1:
Maybe delete the two leading empty
On Mon, 13 Nov 2023 11:47:52 GMT, suchismith1993 wrote:
>>> There is not generic way of generating this. It needs a manual intervention
>>> and symbols are to be added on a need basis in future. Looks like a list to
>>> be maintained. I had tried adding comments to explain the list, but that
>
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
It does beg the question though: Why is AIX not using dynamic loading of the
standard library?
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Okay, I checked the spec for `nativeLinker()`.
* @implNote The libraries exposed by the {@
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
I've done another pass of reading through all comments and background. I think
we're not even ne
On Mon, 13 Nov 2023 07:46:37 GMT, Jorn Vernee wrote:
>>> For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()`
>>> returns a `SymbolLookup` that can be used to find symbols from the standard
>>> library.
>>>
>>> We use a shim library that re-exports symbols from the stand
On Mon, 13 Nov 2023 07:41:11 GMT, Alan Bateman wrote:
> > There is not generic way of generating this. It needs a manual intervention
> > and symbols are to be added on a need basis in future. Looks like a list to
> > be maintained. I had tried adding comments to explain the list, but that
> >
On Fri, 10 Nov 2023 07:56:46 GMT, suchismith1993 wrote:
> > That said, I think we should limit the exported symbols to only those found
> > in the standard C library header files:
> > https://en.cppreference.com/w/c/header
>
> Currently the symbols are restricted to some parts of libc and the
On Fri, 10 Nov 2023 16:30:35 GMT, suchismith1993 wrote:
> There is not generic way of generating this. It needs a manual intervention
> and symbols are to be added on a need basis in future. Looks like a list to
> be maintained. I had tried adding comments to explain the list, but that
> cause
On Mon, 13 Nov 2023 02:32:48 GMT, David Holmes wrote:
> I cannot decide if this is an AIX issue for not using dynamic libraries; a
> FFI issue for assuming dynamic libraries; or a test issue. Won't this be a
> general problem for any function you try to access via FFI that is statically
> link
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
I cannot decide if this is an AIX issue for not using dynamic libraries; a FFI
issue for assumin
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Not even using `nm` on the libraries in question?
The file seem to be consumed by the compiler,
On Fri, 10 Nov 2023 15:48:59 GMT, Magnus Ihse Bursie wrote:
> > Which directory do you suggest to put the exports list in ? Do we create a
> > new directory or use any existing directory.
>
> My initial thinking is like Erik's, that this list should be dynamically
> generated at build-time. I
On Fri, 10 Nov 2023 07:54:40 GMT, suchismith1993 wrote:
> Which directory do you suggest to put the exports list in ? Do we create a
> new directory or use any existing directory.
My initial thinking is like Erik's, that this list should be dynamically
generated at build-time. I am pretty sure
On Thu, 9 Nov 2023 17:46:20 GMT, Erik Joelsson wrote:
> For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()`
> returns a `SymbolLookup` that can be used to find symbols from the standard
> library.
>
> We use a shim library that re-exports symbols from the standard libra
On Wed, 8 Nov 2023 21:11:32 GMT, Magnus Ihse Bursie wrote:
> First and foremost, the `make/data/hotspot-symbols` directory is, as the name
> says, for hotspot symbols. These are not hotspot symbols. If you really do
> need the file, then it needs to reside in a proper location.
>
> Secondly: d
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
> Problem: There is syslookup file which expects the required symbols to be
> exported using the
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()`
returns a `SymbolLoo
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Problem:
There is syslookup file which expects the required symbols to be exported using
the co
On Wed, 8 Nov 2023 21:14:41 GMT, Magnus Ihse Bursie wrote:
> Also, please don't ever force push once you have published a PR. Now it makes
> Martin's comment just dangling in the air.
@magicus I think the force-push happened whilst the PR was still in draft
(skara bot did not complain), which
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
I agree with Magnus that we need to understand the problem first, and then
review the solution.
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Also, please don't ever force push once you have published a PR. Now it makes
Martin's comment j
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
First and foremost, the `make/data/hotspot-symbols` directory is, as the name
says, for hotspot
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
No, no... This is bad on several accounts.
-
PR Comment: https://git.openjdk.org/jd
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Changes requested by mdoerr (Reviewer).
LGTM. You may want to replace the Copyright header of th
56 matches
Mail list logo
