ll to be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request
ll to be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request
On Fri, 7 Jun 2024 13:01:15 GMT, SendaoYan wrote:
>> As confusing as they are, unfortunately GitHub UI does not render extra
>> trailing newlines. This is the only one I could find with grepWin.
>
> I find the extra trailing newlines through below shell command:
>
> for i in `find . -iname
On Fri, 7 Jun 2024 07:26:39 GMT, SendaoYan wrote:
>> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
>>
>>> 1: #
>>
>> This file change is dubious:
>> 1. It does not have any trailing whitespace that can fail the skara checks.
>> 2. If the duplicate blank lines in the end of
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last
On Mon, 3 Jun 2024 09:13:57 GMT, SendaoYan wrote:
>> Hi all,
>> This PR try to fix linux x86_32 configure fail with `--with-hsdis=binutils
>> --with-binutils-src`. The libiberty.a locates in
>> `build/linux-x86-server-fastdebug/configure-support/binutils-install/lib32`
>> on linux ubuntu20.
On Mon, 3 Jun 2024 09:02:47 GMT, Aleksey Shipilev wrote:
> > Don't forget about me! :)
>
> Ah yes, you are also in Build Group now! Apologies.
No worries, I was joking lightheartedly :P
-
PR Comment: https://git.openjdk.org/jdk/pull/19511#issuecomment-2144674185
On Sun, 2 Jun 2024 02:49:47 GMT, SendaoYan wrote:
> Hi all,
> This PR try to fix linux x86_32 configure fail with `--with-hsdis=binutils
> --with-binutils-src`. The libiberty.a locates in
> `build/linux-x86-server-fastdebug/configure-support/binutils-install/lib32`
> on linux ubuntu20. The
On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie wrote:
> Hi Julian, sorry for not getting back to you.
>
> The problem from my PoV is that this is a very large and intrusive patch in
> the build of the actual product, for a claimed problem in the tangential
> hsdis library. I have not
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 t
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 t
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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,
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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,
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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,
ll to be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie 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,
Hi Thomas,
--disable-jvm-feature-link-time-opt is for disabling Link Time
Optimization when compiling the JVM itself, as in, requesting LTO from
the linker that is linking the JVM. It doesn't have anything to do
with what arguments the newly compiled JVM is called with and isn't
related to the
On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote:
> We need to find a better way to handle alloca on AIX.
>
> See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
> e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in
> which three alternatives
On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote:
> We need to find a better way to handle alloca on AIX.
>
> See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
> e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in
> which three alternatives
On Tue, 30 Apr 2024 12:27:42 GMT, Magnus Ihse Bursie wrote:
> Please revert back to the LINK_TYPE name. As long as it is not used for
> anything else, this is a better description. If we start to use it to have a
> broader meaning, we can rename it then.
I switched it back to LANG since in
On Tue, 30 Apr 2024 12:32:09 GMT, Magnus Ihse Bursie wrote:
>> Currently, on Windows LANG is not assigned to C++ for some code that does
>> use C++. This just works because link.exe does not bother about what kind of
>> code it is currently linking. gcc however, does. It doesn't hurt to assign
Currently, on Windows LANG is not assigned to C++ for some code that does use
C++. This just works because link.exe does not bother about what kind of code
it is currently linking. gcc however, does. It doesn't hurt to assign LANG to
C++ as a formality in such cases, which this changeset does.
On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie wrote:
> There's a huge amount of changes for just hsdis... You might have to separate
> out the infrastructure changes that seem to amount to most of the changes
> here.
>
> This is going to take me a while to get through.
Sorry, it's
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
distributions are supported is still to be clarified, as several,
Oops, I meant
__declspec(dllexport) void exportedMethod() {} with braces, not brackets
On Thu, Apr 18, 2024 at 8:27 PM Julian Waters wrote:
>
> I have good (and bad news) for you!
>
> The good news is that from memory, ld and gcc (but I assume you are
> only concerned abo
leaves unexportedMethod as public.
Happy to help!
best regards,
Julian
On Thu, Apr 18, 2024 at 6:28 PM Magnus Ihse Bursie
wrote:
>
> On 2024-04-17 14:06, Julian Waters wrote:
>
> > Hi Magnus,
> >
> > Yes, I'm talking about the MSYS2 objcopy, but to a lesser extent
On Tue, 16 Apr 2024 18:34:49 GMT, Magnus Ihse Bursie wrote:
> There is no good IDE support for Makefiles, especially not with the level of
> customization that we have done to make. I am positively struggling with
> navigating this file, time and time again.
I find Eclipse CDT to be rather
On Wed, 17 Apr 2024 10:54:25 GMT, Joachim Kern wrote:
>> (If some of these files happen to be files which are not compiled on
>> Windows, I assume it will not hurt to drop the ifdef guard, but then again,
>> it can certainly be kept as well for consistency.)
>
> @magicus @TheShermanTanker
On Tue, 16 Apr 2024 09:15:19 GMT, Magnus Ihse Bursie wrote:
>> That was kind of where the discussion started, and which Kim did not like.
>> If I read him correctly, his suggestion was instead to place:
>>
>> #if defined(_AIX)
>> #include
>> #endif
>>
>> in the files where `alloca` is needed
On Wed, 10 Apr 2024 21:10:27 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 Wed, 10 Apr 2024 21:10:27 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 Wed, 10 Apr 2024 21:10:27 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 Wed, 10 Apr 2024 13:51:30 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 Wed, 10 Apr 2024 10:13:37 GMT, Joachim Kern wrote:
>> Can `-Dalloca=__builtin_alloca` replace `#include `?
>
> Yes I believe. I will remove the `#pragma alloca` everywhere, I will remove
> the `#include ` everywhere and I will add
> `-Dalloca=__builtin_alloca` to the compile commands. If
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
On Thu, 4 Apr 2024 22:47:18 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
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
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
On Tue, 2 Apr 2024 20:10:12 GMT, Kim Barrett wrote:
>> I'm waiting for a bunch of tests to complete, so decided to just take that
>> issue.
>
> https://github.com/openjdk/jdk/pull/18586
@kimbarrett I've been doing things to permit gcc/Windows, not clang. clang has
too many different
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 Vis
On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern 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 build. Thus
> the
ve code quality on Windows in the future.
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 awt_Window.cpp
- Labe
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Label to empty line in awt_Component.cpp
- Label to empty line in awt_Canvas.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/p
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Frame.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Component.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openj
On Tue, 26 Mar 2024 20:03:36 GMT, Magnus Ihse Bursie wrote:
>> 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 either way
>
>> Sorry, I don't see a BOOL
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 Vis
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Whitespace in awt_DnDDS.cpp
- Whitespace in awt_DnDDT.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Comment in src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp
Co-authored-by: Magnus Ihse Bursie
- Comment in src/java.desktop
On Tue, 26 Mar 2024 07:44:22 GMT, Magnus Ihse Bursie 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
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting change in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
---
On Mon, 25 Mar 2024 09:02:22 GMT, Magnus Ihse Bursie 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
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Partially revert formatting in AccessBridgeJavaEntryPoints.cpp
- Partially revert formatting in AccessBridgeJavaEntryPoints.cpp
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in awt_Frame.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
- Revert for
On Mon, 25 Mar 2024 08:59:08 GMT, Magnus Ihse Bursie wrote:
>> I don't think I can commit this as there are 3 backticks at the end there :P
>
> Apologies. The point was that this was formatting changes that were not
> needed and should be reverted.
I know, I did want to commit your change
On Fri, 22 Mar 2024 12:27:31 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 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 Vis
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_Window.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
On Fri, 22 Mar 2024 11:38:25 GMT, Magnus Ihse Bursie wrote:
> I can give a spoiler to what the upcoming JDK_LIBS rewrite will do.
>
> Currently, if you want to link with e.g. `jli`, this is what you need to do:
>
> ```
> $(eval $(call SetupJdkLibrary, BUILD_LIBMYLIB, \
> NAME := mylib, \
>
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie 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 84 commits:
>>
>> - Merge branch 'openjdk:master' into patch
On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote:
>> This is the first step of several, in which I will clean up the native
>> compilation code as used by modules. In this first step `java.base`,
>> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
>> they
On Fri, 22 Mar 2024 10:16:44 GMT, Magnus Ihse Bursie wrote:
>> This is the first step of several, in which I will clean up the native
>> compilation code as used by modules. In this first step `java.base`,
>> `java.deskop`, `jdk.accessibility` and `jdk.jpackage` are left out, since
>> they
On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in
On Wed, 20 Mar 2024 16:20:36 GMT, Magnus Ihse Bursie wrote:
> In [JDK-8328157](https://bugs.openjdk.org/browse/JDK-8328157), I rewrote the
> logic to replace -MD with -MT for compiling on Windows. Unfortunately, I
> mistakenly set -MT for all compilers, not just for visual studio.
Looks good.
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie 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?
Hi Magnus, yes I do plan on fixing this. I've just been a bit busy and tired is
all,
On Wed, 20 Mar 2024 06:22:50 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6366:
>>
>>> 6364: jobject parent = data->parentComp;
>>> 6365:
>>> 6366: AwtComponent *awtComponent = nullp
ve code quality on Windows in the future.
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.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/p
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert Formatting in awt_PrintJob.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openj
On Sat, 20 Jan 2024 00:17:02 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 bran
> Compile the JDK as C++17, enabling the use of all C++17 language features
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 11 commits:
- Merge branch 'master' into patch-7
- Require clang 13 in toolchain.m4
- Rem
On Sat, 16 Mar 2024 22:20:53 GMT, Julian Waters wrote:
>> Eclipse Shared Workspaces share the same directory as the JDK itself, which
>> does not make much sense since there can be multiple different
>> configurations of the JDK which Eclipse does depend o
On Wed, 28 Feb 2024 15:07:14 GMT, Julian Waters wrote:
> Eclipse Shared Workspaces share the same directory as the JDK itself, which
> does not make much sense since there can be multiple different configurations
> of the JDK which Eclipse does depend on (as min
On Mon, 18 Mar 2024 10:06:26 GMT, Magnus Ihse Bursie wrote:
>> Side tangent: How are the Workspaces for the other IDEs set up? Are they
>> contained entirely in the ide subdirectory in the build directory or do they
>> end up leaving their metadata in the top level directory like the Shared
On Mon, 18 Mar 2024 09:18:40 GMT, Julian Waters wrote:
>> .gitignore line 22:
>>
>>> 20: /.settings/
>>> 21: /.project
>>> 22: /.classpath
>>
>> `.project` is repeated so that is fine to remove, but why are you removing
>> the
On Mon, 18 Mar 2024 09:07:26 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove SHARED definition in Main.gmk
>
> .gitignore line 22:
>
>>
On Fri, 15 Mar 2024 15:44:48 GMT, Erik Joelsson wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review comments in CreateWorkspace.gmk
>
> Marked as reviewed by erikj (Revie
unlike what this setting suggests. This
> feature was created when I was much less familiar with the structure of how
> the JDK handles different builds, and should be removed
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Remove
On Fri, 15 Mar 2024 12:42:17 GMT, Erik Joelsson wrote:
>> Julian Waters 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 contai
unlike what this setting suggests. This
> feature was created when I was much less familiar with the structure of how
> the JDK handles different builds, and should be removed
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Addre
On Wed, 28 Feb 2024 15:19:58 GMT, Julian Waters wrote:
>> Eclipse Shared Workspaces share the same directory as the JDK itself, which
>> does not make much sense since there can be multiple different
>> configurations of the JDK which Eclipse does depend o
unlike what this setting suggests. This
> feature was created when I was much less familiar with the structure of how
> the JDK handles different builds, and should be removed
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excl
Hi all,
I'm currently working on allowing hsdis to compile under different
Unix environments for Windows with gcc as the compiler, since it's
required for the binutils backend (For good measure I'll throw
capstone support in as well since it's relatively easy to add and it's
also a package under
On Wed, 13 Mar 2024 12:50:17 GMT, Magnus Ihse Bursie wrote:
> According to
> https://github.com/openjdk/jdk/pull/17986#issuecomment-1975396416,
> [JDK-8326583](https://bugs.openjdk.org/browse/JDK-8326583) broke ccache
> compilation.
>
> The reason was that the ccache command line included
>
On Wed, 13 Mar 2024 11:18:20 GMT, Magnus Ihse Bursie wrote:
> As part of the ongoing effort to enable jcheck whitespace checking to all
> text files, it is now time to address assembly (.S) files. The hotspot
> assembly files were fixed as part of the hotspot mapfile removal, so only a
>
On Mon, 12 Feb 2024 14:09:49 GMT, Julian Waters wrote:
>> I have verified that this works fine in the Oracle internal CI.
>>
>> Erik's point still stands:
>>> I still think it would be prudent to verify this patch with all the
>>> currently accepted versions
On Mon, 11 Mar 2024 08:38:53 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
>
> doc/building.html line 679:
>
>> 677: IBM Open XL C/C++
>> 678: The minimum
On Thu, 29 Feb 2024 12:23:37 GMT, Magnus Ihse Bursie wrote:
> After we removed mapfiles, we can setup -fvisibility=hidden (and
> -Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
> compilation.
>
> This will remove duplicate code and make the underlying assumptions of
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 toolchain in the JDK build.
>>
On Thu, 7 Mar 2024 19:53:35 GMT, Andrew John Hughes wrote:
> Also, it might be worth repeating one of my long-standing wishes: that the
> version string should not be hard-coded into the build, but e.g. stored as a
> string in the `release` file, and read from there. If we did that, the cost
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
>
On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder wrote:
> > Could I trouble you to mention what exactly was different?
>
> No trouble at all.
>
> `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is
> where I checked out OpenJDK)
>
> `CCACHE_SLOPPINESS` has the value
1 - 100 of 625 matches
Mail list logo
