On 2022-05-23 19:16, Andrew Leonard wrote:
Hi,
Has anyone looked into reproducible builds for codesign'd MacOS builds?
Basically Apple codesigning is non-deterministic, which is not surprisingly
I guess, so naturally makes reproducible builds a bit tricky. The general
theme for this sort of issue
The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is hard
to follow. This should be straightened out. We also expose variables that are
no longer used. So there's a bit of related cleanup.
The new code is more or less functionally equivalent to the old. There were
some co
On Tue, 24 May 2022 17:09:10 GMT, Magnus Ihse Bursie wrote:
> The logic in BASIC_SETUP_DEVKIT for setting a correct sysroot for Xcode is
> hard to follow. This should be straightened out. We also expose variables
> that are no longer used. So there's a bit of related cleanup.
It is currently both tricky and tedious to figure out what went wrong when a
jtreg test fails in GHA.
We should utilize the full potential of GitHub Action summaries and error
annotations to make finding failures easier and more discoverable.
With this PR, the overview of failures are presented
On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing wrote:
>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates
>> a test module with some resources in it for the actual tests that occur at
>> the native level. The native part was switched to c++ instead of c to make
>> i
On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie wrote:
> It is currently both tricky and tedious to figure out what went wrong when a
> jtreg test fails in GHA.
>
> We should utilize the full potential of GitHub Action summaries and error
> annotations to make finding fail
I encountered a bunch of issues when running with msys2 on Windows (but one of
them could have happened on cygwin as well).
* fixpath must set MSYS2_ARG_CONV_EXCL="*" before running cmd.exe to figure out
the temp directory, or msys might interfere with the command line to cmd.
* Paths like "/c/
On Thu, 2 Jun 2022 09:17:59 GMT, Magnus Ihse Bursie wrote:
> I encountered a bunch of issues when running with msys2 on Windows (but one
> of them could have happened on cygwin as well).
>
> * fixpath must set MSYS2_ARG_CONV_EXCL="*" before running cmd.exe to figure
&g
On 2022-06-02 21:26, Andrey Turbanov wrote:
Hello.
I noticed strange warnings produced by 'make test' recently on my
Win11 installation. For example:
$ make test TEST="tier1"
Building target 'test' in configuration 'windows-x86_64-server-release'
/usr/bin/bash: Files/Git/cmd/git: No such file
On Mon, 6 Jun 2022 12:57:25 GMT, Jaikiran Pai wrote:
>> It is currently both tricky and tedious to figure out what went wrong when a
>> jtreg test fails in GHA.
>>
>> We should utilize the full potential of GitHub Action summaries and error
>> annotations to make finding failures easier and mo
On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya wrote:
> At default configuration, SOURCE_DATE_EPOCH is exported as environment
> variable in SetupReproducibleBuild. Then, gcc is affected of
> SOURCE_DATE_EPOCH environment variable. This value is used only to set
> SOURCE_DATE_ISO_8601 (excep
On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy wrote:
>> Time to start getting ready for JDK 20...
>
> Joe Darcy 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
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin
wrote:
> Hi!
>
> Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea
> of the fix is to re-use value of --with-hotspot-build-time option to generate
> deterministic timestamp exactly like it's done to hotspot componen
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth wrote:
>> One can select a testcase by ID when running a jtreg test case directly from
>> jtreg (using the testcase.java#testID syntax). However, this has not been
>> possible to do when launching jtreg indirectly from make.
>>
>> This fix attempts
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
On Thu, 9 Jun 2022 06:49:15 GMT, KIRIYAMA Takuya wrote:
> The description for the jtreg-failure-handler option is incorrect, so I fixed
> it to describe jtreg-failure-handler option.
> Would you please review this fix?
Marked as reviewed by ihse (Reviewer).
-
PR: https://git.ope
On Wed, 8 Jun 2022 14:46:13 GMT, Magnus Ihse Bursie wrote:
>> With project Skara, the ability to run a set of sanity build and test jobs
>> on selected platforms was added. This functionality was driven by
>> `.github/workflows/submit.yml`. This file unfortunately lacks any
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
On Tue, 7 Jun 2022 22:47:32 GMT, Jonathan Gibbons wrote:
>> make/conf/github-actions.conf line 31:
>>
>>> 29:
>>> 30:
>>> JTREG_URL=https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/330/artifact/jtreg/jtreg-6.1+1.tar.gz
>>> 31:
>>> JTREG_SHA256=ccfa21f54bb173f818a5a8d93f77
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
On Fri, 10 Jun 2022 07:07:11 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Apparently that was not a legal reference to actions/checkout. Try another
>>
On Fri, 10 Jun 2022 07:09:28 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Apparently that was not a legal reference to actions/checkout. Try another
>>
On Fri, 10 Jun 2022 07:14:33 GMT, Aleksey Shipilev wrote:
>> .github/workflows/build-cross-compile.yml line 89:
>>
>>> 87: sudo apt-get install gcc-${{ inputs.apt-gcc-version }}
>>> g++-${{ inputs.apt-gcc-version }} libxrandr-dev${{ inputs.apt-architecture
>>> }} libxtst-dev${{ input
On Fri, 10 Jun 2022 09:43:47 GMT, Magnus Ihse Bursie wrote:
>> Also, I think we can speed up this part by merging two `apt-get install`
>> invocation lines together. It was separate before, because it was two steps,
>> unnecessary now.
>
> Ideally, all version informati
On Fri, 10 Jun 2022 07:18:34 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Apparently that was not a legal reference to actions/checkout. Try another
>&
A few changes to the build system is needed for the GHA rewrite
([JDK-8287906](https://bugs.openjdk.org/browse/JDK-8287906)).
-
Commit messages:
- 8288195: Prepare build system for GHA changes
Changes: https://git.openjdk.org/jdk/pull/9122/files
Webrev: https://webrevs.openjdk.jav
On Fri, 10 Jun 2022 07:23:12 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Apparently that was not a legal reference to actions/checkout. Try another
>>
On Fri, 10 Jun 2022 09:54:36 GMT, Magnus Ihse Bursie wrote:
> A few changes to the build system is needed for the GHA rewrite
> ([JDK-8287906](https://bugs.openjdk.org/browse/JDK-8287906)).
This pull request has now been integrated.
Changeset: d0c8ff8f
Author:Magnus Ihse Bursi
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
On Fri, 10 Jun 2022 11:22:00 GMT, Aleksey Shipilev wrote:
>> I can merge the two `apt-get install` lines, if you say that it is not
>> necessary to call `update-alternatives` before the second install line. (But
>> does it really speed things up?)
>
>> (But does it really speed things up?)
>
>
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicate
On Fri, 10 Jun 2022 11:23:57 GMT, Aleksey Shipilev wrote:
>> If I do that, there need to be some kind of if statement in the called
>> workflow, since if that input argument is left out, we'd get a command line
>> like `sudo dpkg --add-architecture` which I assume is illegal syntax (or,
>> pos
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indica
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indica
On Fri, 10 Jun 2022 07:29:49 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Apparently that was not a legal reference to actions/checkout. Try another
>>
On Fri, 10 Jun 2022 17:11:41 GMT, Alexey Ivanov wrote:
> Update the link to JBS in `vcs.xml` template to https://bugs.openjdk.org/
>
> It will affect newly generated project files only.
> Edit `vcs.xml` manually or in UI to update in existing projects.
Marked as reviewed by ihse (Reviewer).
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
; ### Additional changes outside GHA
>
> I also needed to make a few tweaks to the build system to play nice with the
> new GHA code.
>
> * The build failure summary is now stored in
> build/$BUILD/make-support/failure-summary.log
>
> * The configure summary now indicat
On Mon, 13 Jun 2022 06:45:49 GMT, Magnus Ihse Bursie wrote:
>> With project Skara, the ability to run a set of sanity build and test jobs
>> on selected platforms was added. This functionality was driven by
>> `.github/workflows/submit.yml`. This file unfortunately lacks any
On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya wrote:
> At default configuration, SOURCE_DATE_EPOCH is exported as environment
> variable in SetupReproducibleBuild. Then, gcc is affected of
> SOURCE_DATE_EPOCH environment variable. This value is used only to set
> SOURCE_DATE_ISO_8601 (excep
On Mon, 13 Jun 2022 09:47:48 GMT, Severin Gehwolf wrote:
>> What do you mean by "build time information"?
>
> @magicus I think it's `-Xinternalversion` which has different output between
> Windows and Linux of the same build. But to me that's a feature not a bug.
> From the PR description:
>
>
On Tue, 7 Jun 2022 13:05:49 GMT, Magnus Ihse Bursie wrote:
> With project Skara, the ability to run a set of sanity build and test jobs on
> selected platforms was added. This functionality was driven by
> `.github/workflows/submit.yml`. This file unfortunately lacks any real
> st
On Mon, 13 Jun 2022 06:50:54 GMT, KIRIYAMA Takuya wrote:
>> At default configuration, SOURCE_DATE_EPOCH is exported as environment
>> variable in SetupReproducibleBuild. Then, gcc is affected of
>> SOURCE_DATE_EPOCH environment variable. This value is used only to set
>> SOURCE_DATE_ISO_8601 (
When we started introducing some possibly more intrusive compiler flags and
functionality for reproducible builds, we also introduced a flag to turn this
off out of an abundance of caution. But we have been been using this
configuration for a year or so internally within Oracle, with no issues.
On Tue, 14 Jun 2022 09:48:25 GMT, Magnus Ihse Bursie wrote:
> When we started introducing some possibly more intrusive compiler flags and
> functionality for reproducible builds, we also introduced a flag to turn this
> off out of an abundance of caution. But we have been been u
one from our builds, at least on
> linux and windows. There are no more `__DATE__` and `__TIME__` macros in the
> source code.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Fix exitTransportWithError signature
On Tue, 14 Jun 2022 10:09:37 GMT, Magnus Ihse Bursie wrote:
>> When we started introducing some possibly more intrusive compiler flags and
>> functionality for reproducible builds, we also introduced a flag to turn
>> this off out of an abundance of caution. But we have be
On Tue, 14 Jun 2022 11:54:40 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix exitTransportWithError signature
>
> make/autoconf/flags-ldflags.m4 line 132:
On 2017-09-27 12:45, Maurizio Cimadamore wrote:
On a problematic repo I tried to compare the spec.gmk before/after the
configure run - there's a difference which seems to be causing this
issue:
The buggy spec.gmk (which causes the permission issues) has this:
BUILD_OUTPUT:=/w/master/build/lin
We should use CDS to minimize Java startup time during build. We run
multiple Java commands, and every second counts.
On my machine, I get a ~3% build time speedup with this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8188312
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8188312-use-CDS-
horoughly across all
platforms in JPRT.
Thanks,
David
/Claes
On 2017-10-03 12:28, David Holmes wrote:
Hi Magnus,
As I just put in the bug report, it isn't quite this simple. You
have to be able to tolerate/recover from failure to map the shared
archive.
Cheers,
David
On 3/10/
I gave msys2 a shot some time ago, but it ended up too much trouble.
I'll share some of my notes from that attempt, for what it's worth.
To install package X/Y, run "pacman -S X/Y". Missing tools and packages
where to find them:
cmp: msys/diffutils
tar: msys/tar
make: msys/make
unzip: msys/unz
e:
Looks good to me.
Thanks,
David
On 3/10/2017 10:47 PM, Magnus Ihse Bursie wrote:
On 2017-10-03 14:21, David Holmes wrote:
Erik J. raises a good point in the bug report that
-XX:SharedArchiveFile=xxx should be used if we create the archive.
The build system has no business creating an archiv
nf/spec.gmk.in
--- a/common/autoconf/spec.gmk.inThu Aug 03 18:56:56 2017 +
+++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200
@@ -120,6 +120,13 @@
# On Windows, the Visual Studio toolchain needs the PATH to be adjusted
# to include Visual Studio tools (this needs to be in
rements.
/Magnus
product(bool, VerifySharedSpaces,
false, \
"Verify shared spaces (false for default archive, true for
" \
"archive specified by
-XX:SharedArchiveFile)") \
\
Thanks
- Ioi
On 10/3/17 1:37 PM, Magnus
On 2017-10-04 10:47, Magnus Ihse Bursie wrote:
On 2017-10-04 02:36, Ioi Lam wrote:
If you use SharedArchiveFile, you should set -XX:-VerifySharedSpaces
at the same time.
Long story short -- for security, we don't want bad archives to be
mapped into the JVM.
If you don'
Since the forest consolidation, multiple "paper-cut" issues have appeared.
This patch will deal with the following issues:
* Changes in autoconf files will no longer cause make to require a
reconfigure.
* "make reconfigure" was broken when closed sources were present
* The new relationship betw
On 2017-10-04 16:43, Ioi Lam wrote:
On 10/4/17 2:01 AM, Magnus Ihse Bursie wrote:
On 2017-10-04 10:47, Magnus Ihse Bursie wrote:
On 2017-10-04 02:36, Ioi Lam wrote:
If you use SharedArchiveFile, you should set
-XX:-VerifySharedSpaces at the same time.
Long story short -- for security
ried .configure
--with-output-sync=recurse without success (same symptoms)
Let me know your thoughts.
Best regards,
Peter
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
From: Magnus Ihse Bursie<mailto:magnus.ihse.bur...@oracle.com>
Sent: Wednesday, O
On 2017-10-05 11:07, Claes Redestad wrote:
On 2017-10-05 10:59, Magnus Ihse Bursie wrote:
How often is -Xbootclasspath/p used?
Why not use "-XX:-VerifySharedSpaces -XX:SharedArchiveFile=local.jsa
-Xshare:auto"? That way you will have the start-up benefit if possible.
My worry he
Now that we only have a single repo, the first argument to
IncludeCustomExtension is no longer needed.
I looked at some more ambitious ways to simplify IncludeCustomExtension.
Getting make to automatically retrieve the name of the file is just
so tantalizingly close to possible, but ultima
on that this
happens because make is still running parallel jobs, despite JOBS=1
but I’m not sure.
How could I best tackle this?
Thank you and best regards,
Peter
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows 10
*From: *Magnus Ihse Bursie <mailto:m
On 2017-10-05 18:08, Ioi Lam wrote:
On 10/5/17 2:35 AM, Magnus Ihse Bursie wrote:
On 2017-10-05 11:07, Claes Redestad wrote:
On 2017-10-05 10:59, Magnus Ihse Bursie wrote:
How often is -Xbootclasspath/p used?
Why not use "-XX:-VerifySharedSpaces
-XX:SharedArchiveFile=loca
On 2017-10-09 11:59, Erik Joelsson wrote:
Please review my second attempt at fixing this issue. The last time a
bug in Jib caused problems on Windows. This has now been fixed so we
can apply this patch again.
Bug: https://bugs.openjdk.java.net/browse/JDK-8188910
Webrev: http://cr.openjdk.java
On 2017-10-09 17:29, Erik Joelsson wrote:
After the repo consolidation, I missed updating the
IncludeCustomExtension calls for the JtregNative*.gmk files. This
causes tests to fail for us since the native libraries have not been
built.
Bug: https://bugs.openjdk.java.net/browse/JDK-8188050
We
u...@hotmail.com>
*Sent: *Friday, October 6, 2017 6:43 PM
*To: *Magnus Ihse Bursie <mailto:magnus.ihse.bur...@oracle.com>; Erik
Joelsson <mailto:erik.joels...@oracle.com>; build-dev@openjdk.java.net
<mailto:build-dev@openjdk.java.net>
*Subject: *RE: Building OpenJDK9 on MSYS2
> Peter
>
> Sent from Mail for Windows 10
>
> From: Erik Joelsson
> Sent: Wednesday, October 11, 2017 12:16 PM
> To: Peter Budai; Magnus Ihse Bursie; build-dev@openjdk.java.net
> Subject: Re: Building OpenJDK9 on MSYS2
>
> Hello Peter,
>
>
> On 201
We should remove make/corba/Makefile. This should have been done long
time ago by JDK-8076060.
"Patch":
$ hg st
R make/corba/Makefile
Bug: https://bugs.openjdk.java.net/browse/JDK-8189222
/Magnus
On 2017-10-12 13:37, Alan Bateman wrote:
On 12/10/2017 12:15, Magnus Ihse Bursie wrote:
We should remove make/corba/Makefile. This should have been done long
time ago by JDK-8076060.
"Patch":
$ hg st
R make/corba/Makefile
Bug: https://bugs.openjdk.java.net/browse/JDK-8189222
On 2017-10-11 12:13, Thomas Stüfe wrote:
Hi all,
It seems to me make/nb_native project is not yet fully adapted after
convesion to the new repo structure?
When I open the project, I see all native sources greyed out (in addition
to dead links to the old sources which can just be deleted).
Is a
On 2017-10-12 15:40, Erik Joelsson wrote:
Unfortunately, it didn't stay as easy as that. After hitting snag
after snag, I finally decided to implement some kind of general
support for file names with spaces in them, with support in CacheFind
and SetupCopyFiles, as well as the various install-fi
When creating the consolidated forest, old paths were rewritten
automatically using pattern matching. Unfortunately, this resulted in
incorrect paths in some places.
Specifically, we do not need to look for source code in
$(TOPDIR)/src/*/$(MODULE).
(Actually, some code history digging later
ck with an updated review that will restore the behavior
with respect to closed sources.
/Magnus
On 2017-10-12 16:38, Magnus Ihse Bursie wrote:
When creating the consolidated forest, old paths were rewritten
automatically using pattern matching. Unfortunately, this resulted in
incorrect pat
ke. I believe the former does not leave a trailing space,
so mixing them does not allow for string comparisons.)
Looks good to me now. Except it's still horrible. :-)
/Magnus
/Erik
On 2017-10-12 16:23, Magnus Ihse Bursie wrote:
On 2017-10-12 15:40, Erik Joelsson wrote:
Unfortunately, it didn
Here's an updated webrev:
http://cr.openjdk.java.net/~ihse/JDK-8189229-fix-superfluous-FillCacheFind-paths/webrev.02
/Magnus
On 2017-10-12 17:00, Magnus Ihse Bursie wrote:
Erik commented off-line that this code was intended to include closed
source code. It was indeed correct prior t
To support the use case where the OpenJDK repository is included as part
of a custom project, this patch introduces the concept of a "custom
root", which plays the role of $TOPDIR in some circumstances. It is the
responsibility of any custom code to keep this value and propagate it
where needed
l
world, the OpenJDK code would not have to care about this, but we're not
there yet. So the CUSTOM_ROOT needs to be propagated (and in a few
places, used instead of TOPDIR) into the open part.
/Magnus
Thanks,
David
On 13/10/2017 8:11 PM, Magnus Ihse Bursie wrote:
To support the
On 2017-10-16 10:24, Erik Joelsson wrote:
Hello Roman,
In hotspot.m4, I believe the check on line 328 (pre changes) is still
relevant for just the zero case.
Yes, it is indeed.
Otherwise build changes look good to me.
Agree, looks good.
/Magnus
/Erik
On 2017-10-16 00:00, Roman Kennke
On 2017-10-16 11:34, Erik Joelsson wrote:
In my recent change for JDK-8189095, I changed the quoting of all src
and targets files in the install-macros from single to double. I did
this in an early version of that patch to allow for the shell to match
the ? wildcard. In the final version of the
On 2017-10-16 15:12, Erik Joelsson wrote:
With JDK 9 released, it's high time to change the required boot jdk
for building JDK 10. This time, the change wasn't as straight forward
as it usually is.
It's currently possible to use any of JDK 8, 9 or a recent build of 10
to boot the JDK 10 build
On 2017-10-17 14:11, Erik Joelsson wrote:
The fix in JDK-8189324 wasn't quite complete. The whole SetupCopyFiles
macro still needs to be adjusted to properly handle files with $ in
them. In the previously known two locations where this was an issue,
we currently have explicit calls to DoubleDol
On 2017-10-17 14:32, Erik Joelsson wrote:
In the consolidation restructuring, I missed merging the contents of
make/hotspot/copy/Copy-java.base.gmk with
make/copy/Copy-java.base.gmk. The only relevant part that needs to be
preserved is the optional copying of libffi.so.? which we need when
bui
On 2017-10-17 14:39, David Holmes wrote:
Hi Erik,
Seems reasonable. Though does highlight we still need to close out
8167078.
100% agree. Do you think we can just delete the files that are not
distributed anyway? The bug is assigned to infrastructure, but it's
rather somewhere in the intersec
On 2017-10-17 15:46, Thomas Stüfe wrote:
Hi all,
may I please have a review of this fix. This fixes the nb_native projects
and adapts them to the new repo structure (removing old dead hotspot branch
etc). It also adds a new windows x64 specific platform.
Bug:
https://bugs.openjdk.java.net/brow
The file jvmticmlr.h is stored twice in the repo, both in hotspot and in
java.base. They are both identical, and only the java.base version is
included in the final product. This might arguably have been useful in a
pre-consolidated world, but makes absolutely no sense now.
Bug: https://bugs.o
On 2017-10-17 15:59, Erik Joelsson wrote:
New webrev:
On 2017-10-17 13:10, Magnus Ihse Bursie wrote:
This is a quite complex change. It's a bit unfortunate that we have
to make these kinds of changes to use JDK 9 as a boot JDK. Anyway,
that's the way it is.
A couple of rema
On 2017-10-18 10:26, Erik Joelsson wrote:
On 2017-10-18 10:04, Magnus Ihse Bursie wrote:
The file jvmticmlr.h is stored twice in the repo, both in hotspot and
in java.base. They are both identical, and only the java.base version
is included in the final product. This might arguably have been
The file jni.h is stored twice in the repo, both in hotspot and in
java.base. They are both identical, and only the java.base version is
included in the final product.
This bug is a part of the umbrella effort JDK-8167078 "Duplicate header
files in hotspot and jdk". As for JDK-8189607, my reas
On 2017-10-18 07:39, David Holmes wrote:
On 17/10/2017 11:21 PM, Magnus Ihse Bursie wrote:
On 2017-10-17 14:39, David Holmes wrote:
Hi Erik,
Seems reasonable. Though does highlight we still need to close out
8167078.
100% agree. Do you think we can just delete the files that are not
In the context of JDK-8167078 (Duplicate header files in hotspot and
jdk), I was looking at unifying the platform specific extensions to
jni.h, the jni_md.h files between hotspot and java.base.
The main difference here is that the hotspot jni_* files are divided
into individual files based on
On 2017-10-18 11:29, Erik Joelsson wrote:
New webrev again: http://cr.openjdk.java.net/~erikj/8189094/webrev.03/
Looks good to me!
/Magnus
Removed the ToolProvider patching.
Changed build/tools/symbolgenerator/TransitiveDependencies.java to use
JavacTool directly.
Changed Gendata-jdk.com
From the bug report: "For JSR 383 (Java SE 18.3), we need weekly diffs
of the Java SE 18.3 API specification. The current "doc-javase" makefile
target always uses the most recent version of the javadoc tool (i.e. the
tool that was just built). Unfortunately, this introduces unwanted diffs
that
undle to upload. But then again, maybe such a step should
automatically run specdiff as well.
/Magnus
/Erik
On 2017-10-19 14:30, Magnus Ihse Bursie wrote:
From the bug report: "For JSR 383 (Java SE 18.3), we need weekly
diffs of the Java SE 18.3 API specification. The current "doc-j
On 2017-10-19 15:47, Erik Joelsson wrote:
This patch introduces a new Javac plugin as a build tool, written by
Jan Lahoda. The plugin creates a hash of the public API of what is
being compiled and puts it in a file. The file is only updated if
there is a difference compared to the current conte
On 2017-10-18 13:28, Erik Joelsson wrote:
In preparation for removing fontconfig.h from the jdk src, this change
updates the build procedure for creating the linux devkit by adding
fontconfig to the sysroot, as well as bumping the devkit version to
one with fontconfig included.
Phil, could yo
On 2017-10-20 15:30, Erik Joelsson wrote:
This didn't quite work out. The clean and prep recipes broke down when
ARCHIVE_BUNDLE was empty.
New webrev: http://cr.openjdk.java.net/~erikj/8189664/webrev.02/
Looks good to me.
/Magnus
/Erik
On 2017-10-19 14:32, Erik Joelsson wrote:
In test/Tes
On 2017-10-18 16:14, Thomas Stüfe wrote:
On Wed, Oct 18, 2017 at 3:25 PM, Volker Simonis
wrote:
Hi Goetz,
How do our nightly builds look like? Do they create the JRE image?
Regards,
Volker
Goetz is in a meeting.
None of our AIX builds creates a JRE image. Works on other platforms. Looks
On 2017-10-18 13:55, Erik Joelsson wrote:
When working on a closed feature, I needed access to the list of
source files from a SetupCopyFiles call. This patch adds a specific
variable in which this information is returned.
Webrev: http://cr.openjdk.java.net/~erikj/8187974/webrev.01/
Looks goo
701 - 800 of 3318 matches
Mail list logo
