On Tue, 19 Jan 2021 01:53:03 GMT, David Holmes wrote:
>> We are now confident that we have build-time and runtime support for
>> clock_gettime and CLOCK_MONOTONIC on all our OpenJDK supported POSIX
>> platforms - see bug report for some more details on different OS.
>> Consequently we can
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote:
> This is the security libs portion of the effort to replace
> archaic/non-inclusive words with more neutral terms (see JDK-8253315 for
> details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as
On Tue, 12 Jan 2021 06:46:33 GMT, liach
wrote:
> Though this content seems simple, it would be extremely frustrating to
> newcomers, especially when the build stalls at "cannot find valid visual
> studio installation" for no clear reason in logs at all.
Marked as reviewed by erikj
On Mon, 11 Jan 2021 19:27:12 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8259343: [macOS] Update JNI error handling in Cocoa code.
Build changes look good.
On Mon, 11 Jan 2021 17:52:19 GMT, Phil Race wrote:
>> Proposed updates to JNI error handling.
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8259343: [macOS] Update JNI error handling in Cocoa code.
On Mon, 11 Jan 2021 11:11:01 GMT, Magnus Ihse Bursie wrote:
> COMPARE_BUILD will fail to run the compare stage, since re-applying an
> applied patch does not work.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2025
On Sat, 9 Jan 2021 14:05:10 GMT, Yasumasa Suenaga wrote:
>> I ran configure script on WSL 1, but it failed as below:
>>
>> $ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1
>>
>> :
>>
>> configure: Found potential Boot JDK using configure arguments
>> configure: The
On Thu, 7 Jan 2021 22:01:51 GMT, Erik Joelsson wrote:
> In JDK-8251551, the top level README file changed names to README.md. In
> jib-profiles.js we have a reference to this file to identify if the current
> source tree is likely to be complete. This reference needs to be updated.
On Fri, 8 Jan 2021 14:49:12 GMT, Yasumasa Suenaga wrote:
>> I initially wanted to leave this for Magnus to look at since he wrote all of
>> this, and I know he put a lot of effort into fixpath.sh. It's not a simple
>> script. Now I have stared at it for a while, I think I understand the
>>
On Fri, 8 Jan 2021 13:07:02 GMT, David Holmes wrote:
>> Yasumasa Suenaga has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Refactoring
>
> Hi Yasumasa,
>
> Okay I see the problem case now, and the latest fix seems to fix things in a
>
I agree this would be useful and filed
https://bugs.openjdk.java.net/browse/JDK-8259485
/Erik
On 2021-01-07 21:35, - wrote:
Hello,
This is a followup of
https://mail.openjdk.java.net/pipermail/build-dev/2021-January/029905.html.
In that thread, my build on Windows 10 (not WSL) failed because
In JDK-8251551, the top level README file changed names to README.md. In
jib-profiles.js we have a reference to this file to identify if the current
source tree is likely to be complete. This reference needs to be updated.
-
Commit messages:
- Change reference in jib-profiles.js
On Tue, 5 Jan 2021 22:51:29 GMT, Erik Joelsson wrote:
> This patch changes how the docs-reference make target behaves to better
> support the requirements for it. This target is used to generate javadocs in
> a more stable way between releases, so that they those docs are bett
ocs are built (but still with a separate set of
> parameters).
>
> This fix needs to go into JDK 16 so that the docs-reference target there can
> be used to generate diffs for JDK 17.
Erik Joelsson has updated the pull request incrementally with one additional
commit since the last
On Wed, 6 Jan 2021 02:19:51 GMT, Joe Darcy wrote:
> Updating to the symbol files for JDK 16 b30; change generated with the script
>
> make/scripts/generate-symbol-data.sh
>
> The change to the java.desktop module looks to be for JDK-8258373.
Marked as reviewed by erikj (Reviewer).
This patch changes how the docs-reference make target behaves to better support
the requirements for it. This target is used to generate javadocs in a more
stable way between releases, so that they those docs are better suited for
generating diffs between releases. Currently we use the boot JDK
Hello Matthias,
The path configure found to vcruntime140_1.dll certainly looks strange.
This is likely a bug in the build system. Normally we would expect to
find this file in the redist dir of the Visual Studio installation. Does
your community edition not include that file?
/Erik
On
On Mon, 4 Jan 2021 09:25:55 GMT, Yasumasa Suenaga wrote:
> I got garbled exception message as following when I run `livenmethods` CLHSDB
> command:
>
> sun.jvm.hotspot.debugger.DebuggerException : ?w???W
>
> My Windows laptop is set Japanese Locale, garbled message was written in
>
On Mon, 4 Jan 2021 08:34:02 GMT, Aleksey Shipilev wrote:
> JDK-8256831 added the Zero linkage with libatomic for MIPS, but there are
> other 32-bit Zero platforms that need the same kind of treatment.
>
> Additional testing:
> - [x] linux-mipsel-zero-fastdebug build
Marked as reviewed by
Hello Andy,
Sorry for the late reply, but a lot of us have been on holiday.
I recommend starting with the main documentation in the source tree at
doc/building.md. I have no personal experience using Clang for cross
compilation, but I would imagine it would function similar enough to
GCC. To
On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 15 Dec 2020 23:15:23 GMT, Magnus Ihse Bursie wrote:
> The `templates` directory in `make` is an odd bird. It actually contains data
> files that the license checker needs, so it should move to `make/data`.
Marked as reviewed by erikj (Reviewer).
-
PR:
On Tue, 15 Dec 2020 23:38:02 GMT, Magnus Ihse Bursie wrote:
> The "symbol" files in make/hotspot/symbols are a list of exported symbols
> from libjvm. As such, they are an essential data source for the build system,
> and they should reside in make/data, not mixed with the hotspot make source
On Tue, 15 Dec 2020 21:17:14 GMT, Magnus Ihse Bursie wrote:
>> The file `make/autoconf/version-numbers` is plagued by a two-fold problem:
>> first of all, it's a configuration file, not a part of autoconf, so it
>> should reside in `make/conf` instead of `make/autoconf`.
>>
>> Secondly,
On Tue, 15 Dec 2020 13:11:30 GMT, Magnus Ihse Bursie wrote:
> Right now `CompileJavaModules.gmk` contains two different part: one part with
> the functionality needed to compile a java module, and one part were all
> special requirements for all modules are listed.
>
> The second part should
On Tue, 15 Dec 2020 14:40:34 GMT, Magnus Ihse Bursie wrote:
>> Right now `CompileJavaModules.gmk` contains two different part: one part
>> with the functionality needed to compile a java module, and one part were
>> all special requirements for all modules are listed.
>>
>> The second part
On Thu, 10 Dec 2020 13:11:47 GMT, Magnus Ihse Bursie wrote:
>> The Leaning Toothpick Syndrome[1] strikes back!
>>
>> In the fixpath shell script wrapper, we transform single `` to `\`, to make
>> them correctly escaped. Unfortunately, the bas variable substitution pattern
>> I used were
On Wed, 9 Dec 2020 14:08:32 GMT, Magnus Ihse Bursie wrote:
> It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file
> in the PATH that matches the given tool name, it accept it straight away.
> Even if the file is a directory, or is not executable.
Marked as reviewed by
On Tue, 8 Dec 2020 16:43:14 GMT, Magnus Ihse Bursie wrote:
>> When calling a Windows tool that needs an argument on the form
>> `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks
>> `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and
>> stops trying to
On Tue, 8 Dec 2020 16:40:26 GMT, Magnus Ihse Bursie wrote:
>> When calling a Windows tool that needs an argument on the form
>> `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks
>> `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and
>> stops trying to
On 2020-12-08 00:30, Magnus Ihse Bursie wrote:
On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung wrote:
I have reviewed all lines in the patch file with or near instances of
`jdk.compiler`
Hi Magnus,
I see the motivation of moving these build files for better identification of
ownership.
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie wrote:
>> For the build to work on Windows, we need a unix compatibility layer (known
>> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
>> build system then needs to adapt various aspect to get the build to work in
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote:
> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago
> and supported three different Linux signal API's: sigset, signal and
> sigaction:
>
>
On 2020-12-04 21:22, David Holmes wrote:
Hi Erik,
On 4/12/2020 12:07 am, Erik Joelsson wrote:
In general, I would prefer if a flag like this was just inlined in
the SetupJdkLibrary call, as there are no complex conditionals for
setting it. Looking a bit further, the variable
When building the test-bundle incrementally, it always gets rebuilt. This is
caused by the prepare-test-image target in TestImage.gmk, where we create a
README file as part of a recipe for a PHONY target. This means that the README
is always rebuilt, which in turn triggers downstream rebuilds.
On Fri, 4 Dec 2020 14:44:49 GMT, Erik Joelsson wrote:
> We have historically provided -mmacosx-version-min=10.9.0 flags when
> compiling and linking all our native executables and libraries on Macosx.
> That flag seems to have disappeared when linking libjvm. This is sometimes
>
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote:
> Start of JDK 17 updates.
Build changes look good and I'm happy there are so few of them!
-
Marked as reviewed by erikj (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1531
On Fri, 4 Dec 2020 15:57:44 GMT, Jorn Vernee wrote:
>> @magicus Thanks! But, now I get the same error as the GH action:
>> https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80
>>
>> Looks like `-a` is not supported in my shell. I can make the error go away
>> locally with:
>>
We have historically provided -mmacosx-version-min=10.9.0 flags when compiling
and linking all our native executables and libraries on Macosx. That flag seems
to have disappeared when linking libjvm. This is sometimes causing our macosx
builds to not be able to run on older versions of macosx.
On Fri, 4 Dec 2020 12:45:57 GMT, Magnus Ihse Bursie wrote:
>> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin
>> PATH in .bash_profile. If I remove that I get a little further.
>>
>> But the same command fails later on a path with a space in it:
>>
>> fixpath:
On Thu, 3 Dec 2020 22:39:00 GMT, Magnus Ihse Bursie wrote:
>> make/common/JavaCompilation.gmk line 241:
>>
>>> 239:
>>> 240: $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE)
>>> 241:$(ECHO) portfile=$$($1_JAVAC_PORT_FILE) > $$@
>>
>> Did you consider using WriteFile here?
On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson wrote:
>>> And I can certainly move jdwp.spec to java.base instead.
>>
>> If jdwp.spec has to move to the src tree then src/java.se is probably the
>> most suitable home because Java SE specifies JDWP as an optiona
On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote:
>> And I can certainly move jdwp.spec to java.base instead. That's the reason I
>> need input on this: All I know is that is definitely not the responsibility
>> of the Build Group to maintain that document, and I made my best guess at
>>
On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson wrote:
> After fixing JDK-8256810 and starting to look into backporting it, I
> discovered more potential failing cases. Certain versions of GCC may
> sometimes output multiple prerequisite files on the same line. I think the
>
On Thu, 3 Dec 2020 15:30:15 GMT, Magnus Ihse Bursie wrote:
>> For the build to work on Windows, we need a unix compatibility layer (known
>> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
>> build system then needs to adapt various aspect to get the build to work in
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote:
> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago
> and supported three different Linux signal API's: sigset, signal and
> sigaction:
>
>
s.
>
> When splitting lines, we need to make sure to not just split on any space.
> Some compilers output the : of the rule with a leading space, and already
> split lines will have a space before the backslash.
Erik Joelsson has updated the pull request incrementally with one additiona
On Wed, 2 Dec 2020 22:00:55 GMT, Erik Joelsson wrote:
>> The current intention is to be consistent with the min system version and
>> it's currently set to 10.9. If libjvm.dylib gets a different value, then
>> that would be a bug, but note that this could also var
On Wed, 2 Dec 2020 21:57:15 GMT, Erik Joelsson wrote:
>> Interesting, I still able to run the build after this change on macOS
>> 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm.
>> libjli, libjava have one, and it's 10.9
>
> The current inten
On Wed, 2 Dec 2020 21:32:46 GMT, Anton Kozlov wrote:
>> I wonder if we should be "upping" that to something later.
>> 10.9 is over 7 years old and has been out of support for what - 4 years ?
>
> Interesting, I still able to run the build after this change on macOS 10.9.5.
> I use jdk image and
On Wed, 2 Dec 2020 20:01:08 GMT, Tim Bell wrote:
>> Erik Joelsson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added test
>
> test/make/TestFixDepsFile.gmk line 60:
>
>> 58: $(ECHO) "
s.
>
> When splitting lines, we need to make sure to not just split on any space.
> Some compilers output the : of the rule with a leading space, and already
> split lines will have a space before the backslash.
Erik Joelsson has updated the pull request incrementally with one additiona
On Wed, 2 Dec 2020 17:41:54 GMT, Tim Bell wrote:
>> Erik Joelsson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make newline splitting work with BSD tar to make tests pass on macosx
>
> As @magicus wr
s.
>
> When splitting lines, we need to make sure to not just split on any space.
> Some compilers output the : of the rule with a leading space, and already
> split lines will have a space before the backslash.
Erik Joelsson has updated the pull request incrementally with one additiona
After fixing JDK-8256810 and starting to look into backporting it, I discovered
more potential failing cases. Certain versions of GCC may sometimes output
multiple prerequisite files on the same line. I think the easiest way to handle
this new issue is to split such lines.
When splitting
On Sat, 21 Nov 2020 00:12:30 GMT, Erik Joelsson wrote:
> After fixing JDK-8256751, I noticed that the fix-deps-file macro isn't
> actually doing the right thing at all. It seems clang on Macosx is
> inconsistent with outputting relative or absolute paths in the deps files, so
> so
On Mon, 23 Nov 2020 15:19:18 GMT, Bernhard Urban-Forster
wrote:
>> I think you need to wait for #1350, and then reconcile this patch with that
>> refactoring.
>
> Thanks for all the comments.
>
>> - 40-50 min builds seem to be excessive for just the hotspot build, do
>> youknow what exactly
On Thu, 26 Nov 2020 20:58:38 GMT, Magnus Ihse Bursie wrote:
> For historical reasons, there exists a variety of different implementations
> of awk: awk (the original implementation), gawk (the GNU version), nawk (new
> awk, iirc) and the lesser known mawk.
>
> Things are complicated by the
After fixing JDK-8256751, I noticed that the fix-deps-file macro isn't actually
doing the right thing at all. It seems clang on Macosx is inconsistent with
outputting relative or absolute paths in the deps files, so some files end up
with double WORKSPACE_ROOT in the paths. It's also not
On Fri, 20 Nov 2020 14:35:27 GMT, Erik Joelsson wrote:
> When building with --disable-absolute-paths-in-output and precompiled header
> enabled (both of which are default in release builds), then incremental
> builds of Hotspot fails if a header file is touched.
>
> This is cau
When building with --disable-absolute-paths-in-output and precompiled header
enabled (both of which are default in release builds), then incremental builds
of Hotspot fails if a header file is touched.
This is caused by the deps file the compiler generates is now containing
relative paths, but
On Wed, 18 Nov 2020 10:35:58 GMT, Magnus Ihse Bursie wrote:
> The microsoft toolchain now supports a new "deterministic" build mode. This
> goes a long way towards building properly deterministic. Another important
> feature is that with the deterministic build mode enabled, the -pathmap flag,
On Tue, 17 Nov 2020 19:02:03 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a
>
On Tue, 17 Nov 2020 21:04:08 GMT, Erik Joelsson wrote:
> In Xcode 12.2, the framework JavaVM was removed in the sysroot and all
> (relevant) frameworks inside were just moved one step up so we still find
> things like JavaNativeFoundation and JavaRuntimeSupport. There is however on
On Wed, 18 Nov 2020 09:47:58 GMT, Magnus Ihse Bursie wrote:
> The change from grep to awk in JDK-8244248 and further bug fixed in
> JDK-8244756 still has invalid syntax. This causes some awk (most notably
> gawk, the most commonly used) to complain:
>
> gawk: cmd. line:1: warning: regexp
In Xcode 12.2, the framework JavaVM was removed in the sysroot and all
(relevant) frameworks inside were just moved one step up so we still find
things like JavaNativeFoundation and JavaRuntimeSupport. There is however one
test that currently links explicitly to JavaVM, which fails the build.
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote:
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
It looks like you have
On Tue, 17 Nov 2020 19:31:16 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>>
>> [8256414](https://bugs.openjdk.java.net/browse/JDK-8256414) / #1233 added
>> similar profile to submit workflow, this patch defines `linux-x64-optimized`
>> profile in jib-profile so it can be used by mach5 and added
On Tue, 17 Nov 2020 14:37:22 GMT, Magnus Ihse Bursie wrote:
>> The time has come to actually turn on the support for reproducible builds by
>> default in the jib profiles.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Mon, 16 Nov 2020 12:51:25 GMT, Robin Westberg wrote:
> We should be more explicit about OS and compiler versions used in the GitHub
> Actions builds, to avoid problems caused by unexpected changes to the
> defaults. This patch changes the OS and GCC versions used from ubuntu-latest
>
On Mon, 16 Nov 2020 12:44:08 GMT, Magnus Ihse Bursie wrote:
>> Currently, to use the javac server, a horrendously long command line option
>> is created, looking like this: `--server:portfile=> portfile>:sjavac=`, where the sjavac command has
>> had all spaces replaced by %20. Since Project
On Fri, 13 Nov 2020 17:26:28 GMT, Robin Westberg wrote:
> We should be more explicit about OS and compiler versions used in the GitHub
> Actions builds, to avoid problems caused by unexpected changes to the
> defaults. This patch changes the OS and MSVC versions used from latest
> (currently
On Thu, 12 Nov 2020 22:13:37 GMT, Magnus Ihse Bursie wrote:
> Currently, to use the javac server, a horrendously long command line option
> is created, looking like this: `--server:portfile= portfile>:sjavac=`, where the sjavac command has
> had all spaces replaced by %20. Since Project
On Fri, 13 Nov 2020 01:08:09 GMT, Magnus Ihse Bursie wrote:
>> Currently, to use the javac server, a horrendously long command line option
>> is created, looking like this: `--server:portfile=> portfile>:sjavac=`, where the sjavac command has
>> had all spaces replaced by %20. Since Project
On Fri, 13 Nov 2020 11:48:31 GMT, Robin Westberg wrote:
> We should be more explicit about OS and compiler versions used in the GitHub
> Actions builds, to avoid problems caused by unexpected changes to the
> defaults. This patch changes the OS and Xcode versions used from latest
> (currently
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote:
> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>
> In that review request it was found that the old fix does not work well in
> all cases,
On Mon, 9 Nov 2020 23:31:09 GMT, Jie Fu wrote:
>> Hi all,
>>
>> The gitignore setting for netbeans project seems to be incomplete.
>> Only nbproject/private/ [1] is ignored.
>>
>> But there are also other files under nbproject/, which should be ignored too.
>>
>>
On Mon, 9 Nov 2020 15:25:28 GMT, Jie Fu wrote:
>> .gitignore line 5:
>>
>>> 3: /.idea/
>>> 4: /.vscode/
>>> 5: /nbproject/
>>
>> I believe the existing nbproject/private/ is meant to catch any private
>> files created by someone opening any of the various nbproject directories
>> that exist
On Mon, 9 Nov 2020 18:02:32 GMT, Erik Joelsson wrote:
>> Thanks @erikj79 for your review.
>> Updated.
>>
>> Any comments?
>> Thanks.
>
> You misunderstand me. Adding the following line is fine and will make git
> ignore any nbproject dir in the root of th
On Mon, 9 Nov 2020 12:07:37 GMT, Jie Fu wrote:
> Hi all,
>
> The gitignore setting for netbeans project seems to be incomplete.
> Only nbproject/private/ [1] is ignored.
>
> But there are also other files under nbproject/, which should be ignored too.
>
> $ tree
On Wed, 4 Nov 2020 13:43:58 GMT, Aleksey Shipilev wrote:
>> Marked as reviewed by erikj (Reviewer).
>
> Thank you, @erikj79. Trivial? (I would like to get is soon, in order to
> capture more hs_errs for current failures)
I'm fine with a quick integration of this.
-
PR:
On Wed, 4 Nov 2020 12:59:24 GMT, Aleksey Shipilev wrote:
> Current submit workflow omits `hs_err*.log` and `replay*.log` files, because
> zip matches the paths, and so only the hs_errs/replays in the current dir are
> picked up (and there are none). It should be preceded with `*` to match
On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie wrote:
> With clang 10.0, the compiler now detects a new class of warnings. The
> `misleading-indentation` warning has previously been disabled on gcc for
> hotspot and libfdlibm. Now we need to disable it for clang as well.
Marked as
On Tue, 3 Nov 2020 20:06:35 GMT, Erik Joelsson wrote:
> After building the JDK from clean, the first incremental build of hotspot
> will recompile all of it. This is caused by a difference in the CFLAGS
> generated on the second go. The difference is generated in
> JdkNativeCom
On Tue, 3 Nov 2020 20:43:01 GMT, Magnus Ihse Bursie wrote:
> The man pages in src/$module/man/*.1 is generated from the (unfortunately
> still) closed markdown sources.
>
> These needs to be updated for JDK 16. During this updating, a typo in the GPL
> header is also fixed (which caused
After building the JDK from clean, the first incremental build of hotspot will
recompile all of it. This is caused by a difference in the CFLAGS generated on
the second go. The difference is generated in JdkNativeCompilation.gmk, where
the module specific java header dir is always added to the
On Tue, 3 Nov 2020 13:39:19 GMT, Magnus Ihse Bursie wrote:
> There is a race when compiling build.tools.symbolgenerator.CreateSymbols:
>
> [2020-11-03T07:21:12,118Z] Error: LinkageError occurred while loading main
> class build.tools.symbolgenerator.CreateSymbols
> [2020-11-03T07:21:12,119Z]
On Tue, 3 Nov 2020 13:21:24 GMT, Michael Keck
wrote:
>> @erikj79
>>
>> Ok, here is a completely rewritten portion, which highlights the differences
>> between Cygwin git and Git for Windows.
>>
>> Suggestion:
>>
>> * You need to install a git client. You have two choices, Cygwin git
On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie wrote:
> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not
> exist anymore.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1031
On Mon, 2 Nov 2020 14:40:35 GMT, Erik Joelsson wrote:
> We have at least one java file with a '$' in the name. As we have learned
> over the years, having $ in unexpected places quickly leads to unexpected
> behavior in a shell/make based build. In this case it's our override
&g
On Fri, 30 Oct 2020 17:19:56 GMT, Erik Joelsson wrote:
> In JDK-8206311, when I introduced a new docs build profile, I forgot to add
> the version configure arguments to it. This causes the docs bundles for
> CI/promoted builds to be generated with the default adhoc version in
We have at least one java file with a '$' in the name. As we have learned over
the years, having $ in unexpected places quickly leads to unexpected behavior
in a shell/make based build. In this case it's our override mechanism of java
files that needs protection against expanding such
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote:
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
>
In JDK-8206311, when I introduced a new docs build profile, I forgot to add the
version configure arguments to it. This causes the docs bundles for CI/promoted
builds to be generated with the default adhoc version information instead of
the specific version for that build.
-
On Thu, 29 Oct 2020 22:00:52 GMT, Erik Joelsson wrote:
> When I reorganized top level docs build targets in JDK-8206311, a race was
> introduced. The docs-*-modulegraph targets use the BUILD_JDK to run a build
> tool. For this to work, the BUILD_JDK needs to be ready for usage. In a
On Thu, 29 Oct 2020 20:53:00 GMT, Erik Joelsson wrote:
> The OpenJDK build on Linux will determine if the JVM feature "dtrace" should
> be enabled based on the availability of dtrace on the build host. For Oracle
> produced OpenJDK builds, we implicitly had this disable
When I reorganized top level docs build targets in JDK-8206311, a race was
introduced. The docs-*-modulegraph targets use the BUILD_JDK to run a build
tool. For this to work, the BUILD_JDK needs to be ready for usage. In a normal
native build, this means that the exploded-image-optimize target
The OpenJDK build on Linux will determine if the JVM feature "dtrace" should be
enabled based on the availability of dtrace on the build host. For Oracle
produced OpenJDK builds, we implicitly had this disabled because our build
environment didn't have it installed. Rather than having to trust
On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad wrote:
> A microbenchmark with --enable-preview was added in JDK-8248135. This had the
> unintended side effect that we now had to always run with --enable-preview.
>
> With records out of preview, I think the best course of action now is to
On Wed, 28 Oct 2020 18:42:01 GMT, Magnus Ihse Bursie wrote:
> The fix for JDK-8235710 (Remove the legacy elliptic curves) unfortunately did
> not remove all code related to elliptic curves in the build system.
Marked as reviewed by erikj (Reviewer).
-
PR:
401 - 500 of 4242 matches
Mail list logo
