On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently, which gcc
On Wed, 3 Apr 2024 02:38:21 GMT, Julian Waters wrote:
>> Bumping
>
>> @TheShermanTanker I tried to help you get this done. I added fixes to a copy
>> of your branch on my personal fork, but then it turned out I could not push
>> them to your branch. :-(
>>
>> It ended up with me creating a
On 2024-04-25 20:30, Philip Race wrote:
On 4/24/24 4:24 AM, Magnus Ihse Bursie wrote:
That is a good question. libiconv is used only on macOS and AIX, for
a few libraries, as you say. I just tried removing -liconv from the
macOS dependencies and recompiled, just to see what would happen
That is a good question. libiconv is used only on macOS and AIX, for a
few libraries, as you say. I just tried removing -liconv from the macOS
dependencies and recompiled, just to see what would happen. There were
three instances for macOS: libsplashscreen, libjdwp and libinstrument.
Out of
On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters wrote:
> WIP
>
> This changeset contains hsdis for Windows/gcc Port. It supports both the
> binutils and capstone backends, though the LLVM backend is left out due to
> compatibility issues encountered during the build. Currently, which gcc
>
On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters wrote:
> WIP
>
> This changeset contains hsdis for Windows/gcc Port. It supports both the
> binutils and capstone backends, though the LLVM backend is left out due to
> compatibility issues encountered during the build. Currently, which gcc
>
On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie wrote:
> The file to build most of the java.desktop native libraries,
> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>
> I want to split it into two parts, one for the AWT libraries, and one f
On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie wrote:
>> The file to build most of the java.desktop native libraries,
>> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>>
>> I want to split it into two parts, one for the AWT libraries
On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie wrote:
>> The file to build most of the java.desktop native libraries,
>> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>>
>> I want to split it into two parts, one for the AWT libraries
On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie wrote:
>> The file to build most of the java.desktop native libraries,
>> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>>
>> I want to split it into two parts, one for the AWT libraries
On Fri, 12 Apr 2024 22:44:35 GMT, Phil Race wrote:
>> @prrace I will need your assistance in confirming that my understanding
>> about the AWT vs 2D split is correct. In particular, `libosxui` gave me some
>> headache, but after trying to dig into the code my understanding ended up
>> being
hange the order to be more
> logical (e.g. grouping "image" libraries and "font" libraries in 2D).
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revision:
- Make the split based on the name "awt" instead, a
hange the order to be more
> logical (e.g. grouping "image" libraries and "font" libraries in 2D).
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
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly us
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the cod
On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie wrote:
> The file to build most of the java.desktop native libraries,
> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>
> I want to split it into two parts, one for the AWT libraries, and one f
On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie wrote:
> The file to build most of the java.desktop native libraries,
> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>
> I want to split it into two parts, one for the AWT libraries, and one f
On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie wrote:
> The file to build most of the java.desktop native libraries, t
> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>
> I want to split it into two parts, one for the AWT libraries, and one f
On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie wrote:
> The file to build most of the java.desktop native libraries, t
> Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>
> I want to split it into two parts, one for the AWT libraries, and one f
The file to build most of the java.desktop native libraries, t
Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
I want to split it into two parts, one for the AWT libraries, and one for the
2D libraries. I also used this opportunity to change the order to be more
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 p
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
@TheShermanTanker. I
> have stepped in and fixed the remaining comments, reverted some additional
> unneeded changed code, and also tried to minimize code duplication in
> `awt_PrintJob.cpp`.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge o
On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons wrote:
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible
On Wed, 3 Apr 2024 02:38:21 GMT, Julian Waters wrote:
> I will keep this open until the other Pull Request has been integrated, in
> case this might still be needed
I don't think it is necessary. You can always re-open a PR if it should be
needed, and you can look at source code and comments
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 majority of the work in this PR has been done by @TheShermanTanker. I have
On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Labels to empty line in awt_Window.cpp
>> - Labels to empty line in awt_Window.cpp
>> - Label to empty line in
On Sat, 20 Jan 2024 00:38:04 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into
On Fri, 22 Mar 2024 12:26:25 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert Formatting in awt_Component.cpp
>> - Revert Formatting in awt_Window.cp
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Wed, 27 Mar 2024 07:13:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Tue, 26 Mar 2024 08:44:31 GMT, Julian Waters wrote:
> Maybe as a further improvement, I can inline
> THROW_NULL_PDATA_IF_NOT_DESTROYED at its callsites and replace the bad
> NullPointerException error message with the proper null pointer name. Since
> Phil isn't here, what do you think?
On Wed, 20 Mar 2024 06:44:02 GMT, Julian Waters wrote:
>> Sorry, I don't see a BOOL error anywhere?
>
> I see the advantage of collapsing self and parent into the same check, but it
> doesn't seem like getting rid of pData is of much benefit, the checks for
> null seem to remain the same
On Tue, 26 Mar 2024 08:55:56 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Tue, 26 Mar 2024 00:13:09 GMT, Julian Waters wrote:
> I have a concern since the null check bailout involves
> THROW_NULL_PDATA_IF_NOT_DESTROYED, which is no longer accurate if we remove
> the pData local.
The name of the macro is not great, but it does not involve pData (the bad NPE
; src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
>
> Co-authored-by: Magnus Ihse Bursie
src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 230:
> 228: }
> 229:
> 230: AwtCanvas *c = (AwtCanvas*) pData;
Suggestion:
AwtCanvas *c = (AwtCanvas*)pD
On Mon, 25 Mar 2024 05:56:52 GMT, Julian Waters wrote:
> The only thing I'm uncertain about is the pData local, which I don't see much
> benefit in removing since the null check associated with it still has to
> remain for code semantics to be correct
The point is that you can do the null
On Mon, 25 Mar 2024 05:58:41 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1230:
>>
>>> 1228: jdouble imgY = (jdouble) ((yPixelOrg * 72)/(jdouble) yPixelRes);
>>> 1229: jdouble imgWid = (jdouble) ((imgPixelWid * 72)/(jdouble)
>>>
On Fri, 22 Mar 2024 10:49:13 GMT, Julian Waters wrote:
>> bot-keep-alive
>>
>> @TheShermanTanker Did you understand the remaining changes that Phil has
>> requested? Do you think you'll be able to fix this?
>
> @magicus Phil doesn't seem to be responding to my queries, I'm not too sure
>
On Sat, 20 Jan 2024 00:40:40 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into
On Sat, 20 Jan 2024 00:32:19 GMT, Phil Race wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge branch 'openjdk:master' into
On Fri, 3 Nov 2023 02:39:26 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 61:
>>
>>> 59:
>>> 60: jfieldID AwtPrintDialog::pageID;
>>> 61:
>>
>> where and why did this come from ?
>
> This came from below, all I did was move it up and out of
On Sun, 3 Dec 2023 15:37:47 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1641:
>>
>>> 1639: }
>>> 1640: }
>>> 1641:
>>
>> A possible improvement later (and for a future RFE) would be to use RAII for
>> deletion and then get rid of
On Wed, 20 Mar 2024 06:38:59 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Sun, 21 Jan 2024 07:58:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
Similar to [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), we want
to move the setting of LDFLAGS to LDFLAGS_JDK[LIB/EXE into SetupJdkLibrary and
SetupJdkExecutable.
-
Commit messages:
- 8328177: Move LDFLAGS_JDK[LIB/EXE] to JdkNativeCompilation.gmk
Changes:
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the cod
On Thu, 14 Mar 2024 12:36:05 GMT, Magnus Ihse Bursie wrote:
> We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
> `CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
> in basically all calls to `SetupJdkLibrary` and `SetupJdkE
We are setting one of the flags `CFLAGS_JDKLIB`, `CXXFLAGS_JDKLIB`,
`CFLAGS_JDKEXE` or `CXXFLAGS_JDKEXE` to `CFLAGS` or `CXXFLAGS`, respectively,
in basically all calls to `SetupJdkLibrary` and `SetupJdkExecutable`.
These flag variables contain a lot of duplication.
The first step towards
We are adding LIBCXX to LIBS in calls to SetupJdkLibrary whenever LINK_TYPE is
C++. We should do this automatically in SetupJdkLibrary for C++ linking.
I also removed the superfluous `-lc` from some places where it had been added.
-
Commit messages:
- 8328146: Set LIBCXX
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to li
On Wed, 13 Mar 2024 09:50:20 GMT, Joachim Kern wrote:
> e.g. We should change the HOTSPOT_TOOLCHAIN_TYPE=xlc to aix, because it is
> not toolchain, but OS related. As a consequence the globalDefinitions_xlc.hpp
> will become globalDefinitions_aix.hpp
No, it's not that simple. First, the
On Wed, 13 Mar 2024 08:50:10 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Replace CC_VERSION_OUTPUT with CC_VERSION_STRING
>> - We need CC_VERS
On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK bu
On Mon, 11 Mar 2024 12:27:08 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 940:
>
>&
On Mon, 11 Mar 2024 12:44:55 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> With this change added, currently configure f
, and should be removed.
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revision:
- Replace CC_VERSION_OUTPUT with CC_VERSION_STRING
- We need CC_VERSION_OUTPUT before we can check it
-
Changes:
- all: https://git.openjdk.
On Tue, 12 Mar 2024 15:15:27 GMT, Magnus Ihse Bursie wrote:
>> make/autoconf/toolchain.m4 line 409:
>>
>>> 407: #Target: powerpc-ibm-aix7.2.0.0
>>> 408: #Thread model: posix
>>> 409: #InstalledDir: /opt/IBM/openxlC/17.1.0/bin
&g
On Mon, 11 Mar 2024 09:14:27 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 409:
>
>
On Mon, 11 Mar 2024 13:45:46 GMT, Joachim Kern wrote:
>> OK this was a flaw in my introduction of clang toolchain for AIX. The
>> intention was to keep the xlc options in form of their clang counterparts. I
>> will try with a corrected version for clang on AIX and will come back to you.
>
>
On Tue, 12 Mar 2024 15:07:15 GMT, Magnus Ihse Bursie wrote:
>>> Is Open XL C/C++ considered a compiler or more akin to a development
>>> environment like Xcode is for macOS? Depending on which, we could just say
>>> clang is the compiler for AIX without
On Tue, 12 Mar 2024 15:04:56 GMT, Magnus Ihse Bursie wrote:
>> Is Open XL C/C++ considered a compiler or more akin to a development
>> environment like Xcode is for macOS? Depending on which, we could just say
>> clang is the compiler for AIX without needing to say that
On Mon, 11 Mar 2024 09:30:20 GMT, Julian Waters wrote:
> Is Open XL C/C++ considered a compiler or more akin to a development
> environment like Xcode is for macOS? Depending on which, we could just say
> clang is the compiler for AIX without needing to say that Open XL is treated
> like
, and should be removed.
Magnus Ihse Bursie has updated the pull request incrementally with two
additional commits since the last revision:
- Set JVM_PICFLAG="-fpic -mcmodel=large" for AIX
- Open XL 17.1.1.4 is clang 15.
-
Changes:
- all: https://git.openjdk.org/jdk/pu
On Mon, 11 Mar 2024 13:54:02 GMT, Alexander Scherbatiy
wrote:
> The fix provides ability to print Black & White pages on macOS.
>
> Cocoa API has
> [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode)
> function but it is marked
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchai
, and should be removed.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Revert SEARCH_PATH changes
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18172/files
- new: https://git.openjdk.org/jdk/pull/18172/fi
On Fri, 8 Mar 2024 15:44:48 GMT, Magnus Ihse Bursie wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchai
On Fri, 8 Mar 2024 15:41:16 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/toolchain.m4 line 444:
>
On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK bu
On Fri, 8 Mar 2024 15:29:58 GMT, Magnus Ihse Bursie wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK bu
As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the
JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by
another name, and it uses the clang toolchain in the JDK build. Thus the old
xlc toolchain is no longer supported, and should be removed.
On Mon, 4 Mar 2024 11:45:59 GMT, Julian Waters wrote:
> I do hope that dropping ccache support isn't something that's planned though
> :(
Not really. The benefit of dropping it is quite small, and there might be use
cases where it helps.
But I think we should perhaps be more explicit in the
On Mon, 4 Mar 2024 06:42:30 GMT, Julian Waters wrote:
> I wonder if it's the SetupToolchain changes that has caused this. ccache is
> collapsed into CC and CXX to my knowledge
Yeah, it must have been. Would you like to take a look at it? Otherwise I'll
file a bug and fix it. Breaking ccache
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to li
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to li
On Wed, 28 Feb 2024 11:24:06 GMT, Magnus Ihse Bursie wrote:
> This is part of a general "spring cleaning" of the build system, addressing
> old code that has bit-rotted, been subject to lava flow, or just had bad or
> smelly code that we've never gotten around to fix.
&
This is part of a general "spring cleaning" of the build system, addressing old
code that has bit-rotted, been subject to lava flow, or just had bad or smelly
code that we've never gotten around to fix.
This particular patch tries to make MakeBase truly minimal; only including the
core parts
On Tue, 27 Feb 2024 11:44:31 GMT, Daniel Jeliński wrote:
> FWIW, when I added -lstdc++ before both -static-libstdc++ and replaced LDCXX
> with LD, the code compiled and linked just fine.
Both GCC and G++ call the same linker, and the parameter differences are well
documented. It's only a
e SetupNativeCompilation code, and
> make it much clearer if we use the C or C++ linker.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains five commits:
- Merge branch 'master' into remove-toolchain-define
- Rena
On Tue, 27 Feb 2024 08:14:56 GMT, Julian Waters wrote:
> can we get rid of LDCXX?
Yeah, that is something I plan to look into. Linking C++ object files with gcc
will fail; and it might be that linking pure C with g++ might be problematic.
If this is the case, I hope we can at least determine
On Tue, 27 Feb 2024 08:29:44 GMT, Julian Waters wrote:
> All those new parameters to SetupNativeCompilation, were they always there
> and the comments about them were just missing from the documentation about
> the function?
Yep. The toolchain definition was a way to "package" multiple
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
On Sat, 24 Feb 2024 06:04:40 GMT, Julian Waters wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>>
e SetupNativeCompilation code, and
> make it much clearer if we use the C or C++ linker.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Rename LANG to LINK_TYPE
-
Changes:
- all: https://git.openjdk.org/jdk/pul
e SetupNativeCompilation code, and
> make it much clearer if we use the C or C++ linker.
Magnus Ihse Bursie has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains three commits:
- Reword "lib" comment to fit in better
- Mer
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This
The idea of setting up general "toolchains" in the native build was good, but
it turned out that we really only need a single toolchain, with a single twist:
if it should use CC or CPP to link. This is better described by a specific
argument to SetupNativeCompilation, LANG := C++ or LANG := C
On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote:
> Since jcheck only checks file in a commit, there is a possibility of us
> getting files in the repository that would not be accepted by jcheck. This
> can happen when extending the set of files checked by jcheck, or
On Sun, 21 Jan 2024 07:58:11 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less
On Thu, 15 Feb 2024 17:53:41 GMT, Naoto Sato wrote:
>> `\u000b` is VT (vertical tab)
>> `\u0009` or `\t` perhaps?
>
> Right. `\t` is better to avoid such a mistake.
Ok, fixed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17871#discussion_r1492403403
xes).
>
> I have now run jcheck over the entire code base, and fixed a handful of
> issues. With these changes, jcheck accept the entire code base.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Replace spaces with \t in
On Thu, 15 Feb 2024 14:01:46 GMT, Erik Joelsson wrote:
>> test/jdk/java/util/Currency/currency.properties line 18:
>>
>>> 16: SB=EUR,111,2, 2099-01-01T00:00:00
>>> 17: US=euR,978,2,2001-01-01T00:00:00
>>> 18: ZZ = ZZZ , 999 , 3
>>
>> This looks weird, but so did
On Thu, 15 Feb 2024 12:19:31 GMT, Magnus Ihse Bursie wrote:
> Since jcheck only checks file in a commit, there is a possibility of us
> getting files in the repository that would not be accepted by jcheck. This
> can happen when extending the set of files checked by jcheck, or
Since jcheck only checks file in a commit, there is a possibility of us getting
files in the repository that would not be accepted by jcheck. This can happen
when extending the set of files checked by jcheck, or if jcheck changes how it
checks files (perhaps due to bug fixes).
I have now run
On Fri, 9 Feb 2024 13:35:55 GMT, Magnus Ihse Bursie wrote:
> This is an attempt to finally implement the idea brought forward in
> JDK-8295729: Properties files is essentially source code. It should have the
> same whitespace checks as all other source code, so we don't get
1 - 100 of 236 matches
Mail list logo
