On Thu, 4 Apr 2024 16:02:53 GMT, Magnus Ihse Bursie wrote:
> This patch will fix the few remaining places where a "raw" call to
> SetupNativeCompilation was made, instead of going via
> SetupJdkNativeCompilation. This include repairing the poor old X11Wrapper,
> which has been broken for some
On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie wrote:
> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>
> I tried to fix the remaining issues in that PR, but could not push them. In
> the end, it seemed easier to create a new branch in my own personal fork.
>
> The majori
On Thu, 4 Apr 2024 20:56:02 GMT, Magnus Ihse Bursie wrote:
>> I was not aware of such a convention and I can't say I agree with it. It
>> just seems redundant and unnecessary, but I suppose we should wait for
>> Magnus to respond.
>
> Just to clarify: I did not say the name needed to be long, j
On Fri, 5 Apr 2024 05:48:40 GMT, Julian Waters wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains two
>> additional co
On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Fri, 5 Apr 2024 09:25:49 GMT, Magnus Ihse Bursie wrote:
>> Thanks. Yes, the long name was my doing. Sorry.
>
> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän"
> prejudice of German. ;-)
>
>
>
> (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone)
On Fri, 5 Apr 2024 08:21:09 GMT, Severin Gehwolf wrote:
>> Just to clarify: I did not say the name needed to be long, just that many
>> (if not all) tools has used the convention of using the package name
>> `build.tools.` and the class name `.java`.
>>
>> I think the new name sounds 👍 .
>
>
> Hi, please consider.
>
> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
> Tested with gcc and clang, and llvm and binutils backend.
>
> I didn't find any use of the "DLL_ENTRY", so I removed it.
>
> Thanks, Robbin
Robbin Ehn has updated the pull request incremental
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>> Thank
On Fri, 5 Apr 2024 09:31:18 GMT, Severin Gehwolf wrote:
>> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän"
>> prejudice of German. ;-)
>>
>>
>>
>> (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone)
>
> Hah! My kids just recently informed me about
>
> Hi,
> Can you help to review the patch?
> This pr is based on previous work and discussion in [pr
> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
> 18294](https://github.com/openjdk/jdk/pull/18294).
>
> Compared with previous prs, the major change in this pr is to integrate the
> sou
On Thu, 4 Apr 2024 16:47:44 GMT, Magnus Ihse Bursie wrote:
> Build libsleef using their cmake system and look at the compile command line.
> (You do this by `VERBOSE=1 cmake` IIRC). Then you can see what flags they are
> using. This is what I was referring to as "normal libsleef build". I notic
On Thu, 4 Apr 2024 21:55:54 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> make/modules/jdk.incubator.vector/Lib.gmk line 44:
>
>>
On Fri, 5 Apr 2024 10:45:24 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>> Thanks
On Fri, 5 Apr 2024 10:42:31 GMT, Robbin Ehn wrote:
> Since windows build seems to need HSDIS_TOOLCHAIN_DEFAULT_CFLAGS
Rght. That is since we use a completely different compiler, gcc instead of
cl. (Which is probably the worst hack in all of the JDK build system...)
-
PR Commen
On Fri, 5 Apr 2024 12:43:30 GMT, Magnus Ihse Bursie wrote:
> > Since windows build seems to need HSDIS_TOOLCHAIN_DEFAULT_CFLAGS
>
> Rght. That is since we use a completely different compiler, gcc instead
> of cl. (Which is probably the worst hack in all of the JDK build system...)
I plan o
On Fri, 5 Apr 2024 09:56:48 GMT, Magnus Ihse Bursie wrote:
> This is the pinnacle of the recent stream of refactorings in the build
> system. This patch introduces a more abstract concept of "JDK_LIBS", where
> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and
> the
This is the pinnacle of the recent stream of refactorings in the build system.
This patch introduces a more abstract concept of "JDK_LIBS", where only the
library name (e.g. "java" or "java.desktop:jawt") is specified, and the build
system turns this into suitable linker flags: `-ljawt -L` or
`
> This is the pinnacle of the recent stream of refactorings in the build
> system. This patch introduces a more abstract concept of "JDK_LIBS", where
> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and
> the build system turns this into suitable linker flags: `-ljawt -
On Fri, 5 Apr 2024 14:14:35 GMT, Magnus Ihse Bursie wrote:
>> This is the pinnacle of the recent stream of refactorings in the build
>> system. This patch introduces a more abstract concept of "JDK_LIBS", where
>> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and
>>
On Fri, 5 Apr 2024 14:01:29 GMT, Julian Waters wrote:
> I plan on adding support for using gcc to compile hsdis on Windows sometime
> soon (Like proper support for gcc as a toolchain on Windows, at least enough
> to support hsdis, so people can freely use any gcc instead of only being
> restri
On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Fri, 5 Apr 2024 14:14:35 GMT, Magnus Ihse Bursie wrote:
>> This is the pinnacle of the recent stream of refactorings in the build
>> system. This patch introduces a more abstract concept of "JDK_LIBS", where
>> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and
>>
On Fri, 5 Apr 2024 10:11:02 GMT, Magnus Ihse Bursie wrote:
> The syntax for specifying JDK libraries can of course be discussed. I tried
> to align it with the current syntax for specifying source code, but it does
> not match 100%. The differences are:
>
> * For source code, the default modul
24 matches
Mail list logo