Hi,
Could you please approve the following backport to 8u-dev?
JBS: https://bugs.openjdk.java.net/browse/JDK-8079788
jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/rev/d57780478145
Code review:
http://mail.openjdk.java.net/pipermail/build-dev/2016-August/017566.html
The patch applies cle
Looks good (except for my spelling error in the comment "siutations".
Not sure what the policy is for fixing such in backports.)
/Erik
On 2018-05-29 05:27, Alexey Ivanov wrote:
Hi,
Could you please approve the following backport to 8u-dev?
JBS: https://bugs.openjdk.java.net/browse/JDK-807978
I can fix it before pushing.
Regards,
Alexey
On 29/05/2018 15:13, Erik Joelsson wrote:
Looks good (except for my spelling error in the comment "siutations".
Not sure what the policy is for fixing such in backports.)
/Erik
On 2018-05-29 05:27, Alexey Ivanov wrote:
Hi,
Could you please appr
The generator script for the new windows 2017 devkit has a bug. It puts
the 64bit redistributable runtime libraries in the 32 bit tools dir.
This causes the 32 bit tools to only work on machines with VS2017
already installed on them. This patch fixes the script to copy the
correct DLLs.
Bug:
Looks good.
-phil.
On 05/29/2018 10:54 AM, Erik Joelsson wrote:
The generator script for the new windows 2017 devkit has a bug. It
puts the 64bit redistributable runtime libraries in the 32 bit tools
dir. This causes the 32 bit tools to only work on machines with VS2017
already installed on t
Looks good.
..Thomas
On Tue, May 29, 2018 at 7:54 PM, Erik Joelsson wrote:
> The generator script for the new windows 2017 devkit has a bug. It puts the
> 64bit redistributable runtime libraries in the 32 bit tools dir. This causes
> the 32 bit tools to only work on machines with VS2017 already
Erik:
Looks good to me as well.
/Tim
On 05/29/18 10:58, Phil Race wrote:
Looks good.
-phil.
On 05/29/2018 10:54 AM, Erik Joelsson wrote:
The generator script for the new windows 2017 devkit has a bug. It
puts the 64bit redistributable runtime libraries in the 32 bit tools
dir. This causes t
The nashorn module requires some special handling when being built.
Because of this, it's not currently compiled like the other modules, in
CompileJavaModules.gmk, but instead in a separate BuildNashorn.gmk.
While nashorn still needs some special treatment, because of the nasgen
tool, this can
The UnpackSecurity.gmk build logic has never belonged in OpenJDK and
should be moved to Oracle's internal makefiles.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203946
Webrev: http://cr.openjdk.java.net/~erikj/8203946/webrev.01/
/Erik
Erik:
The nashorn module requires some special handling when being built.
Because of this, it's not currently compiled like the other modules, in
CompileJavaModules.gmk, but instead in a separate BuildNashorn.gmk.
While nashorn still needs some special treatment, because of the nasgen
tool, this
Erik:
The UnpackSecurity.gmk build logic has never belonged in OpenJDK and
should be moved to Oracle's internal makefiles.
Bug: https://bugs.openjdk.java.net/browse/JDK-8203946
Webrev: http://cr.openjdk.java.net/~erikj/8203946/webrev.01/
Looks good.
/Tim
Could someone help to create a bug etc?
Thanks,
Ao Qi
Magnus Ihse Bursie 于2018年5月25日周五 下午
3:42写道：
> On 2018-05-24 03:08, Ao Qi wrote:
> Hi Erik,
> Thanks for your comments. I made a new patch:
> $ hg diff
> diff -r 31361382634b make/autoconf/build-aux/config.guess
> --- a/make/autoconf/build-
12 matches
Mail list logo
