Hi Moshe,
Can you update your VS 2017 installation? The only difference I can spot
is that we are using
Microsoft Visual Studio 2017 15.9.6
with
Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1
while you have:
Visual Studio 2017 Developer Command Prompt v15.0.26228.86
with
Hi Andrew,
Oh dear. Experience has shown me (and probably you, too) that this is
one of the most error-prone parts of software development. Many
very serious failures have been caused by trying to shut up
compilers. These failures have even included major security breaches.
Fair enough. But
Hi Kim,
Kim Barrett writes:
>
> I think the solution here is to use placement new, but explicitly qualified
> to actually get there, e.g.
>
> ::new (reg_map) RegisterMap(map);
>
> Using unqualified new will do the lookup in RegisterMap, find some
> declarations in StackObj (but not the one we
New webrev at
https://cr.openjdk.java.net/~weijun/8193255/webrev.01
Changes:
1. Textual info at the beginning of each cert
2. Makefile: indentation, BUILD_TOOLS_JDK, MakeTargetDir, files instead of dir
Thanks,
Max
> On May 31, 2019, at 1:34 AM, Erik Joelsson wrote:
>
> On 2019-05-30
Sure. How many info do you want to see?
I can prepend `keytool -printcert` but that's too much. At least I think the
extensions part is not needed. Also, I don't wish people reading the
fingerprint inside as genuine and does not calculate it from the cert itself.
So, I'm thinking of
Owner:
One suggestion is to put a printable form of the contents of the
certificate at the top of each of the PEM files. It would be nice as a
quick-look to see what is in the certificate. Of course, you can also
use keytool -printcert to do that, but if I am just perusing the source
code via a
Hi Max,
first of all, thanks for doing this enhancement. That'll really help in the
future when downstream vendors merge in additional certificates (or remove
some) like we do with SapMachine. Currently we have to resolve manually
everytime cacerts is modified.
As for the dependencies: if you
Hi David. I have done it. with same result.
I have added --debug-configure flag.. Attaching full configure output..
I am stuck with this issue and right now - have no idea - how to get out of
this "blind alley"...
чт, 30 мая 2019 г. в 12:46, David Holmes :
> Hi Moshe,
>
> can you try running
Erik:
This patch changes the help text printed when the bootjdk is
missing to "OpenJDK distributions are available at
http://jdk.java.net/.; and removes all the OS specific help texts for
that particular dependency.
Bug: https://bugs.openjdk.java.net/browse/JDK-8219788
Configure tries to be helpful with suggested commands for installing
missing dependencies. The commands for installing a bootjdk are out of
date and because of the accelerated release cycle, don't really work
anymore. This patch changes the help text printed when the bootjdk is
missing to
Looks good.
/Erik
On 2019-05-30 10:54, Jonathan Gibbons wrote:
In creating the changeset for JDK-8224257, I forgot to 'hg add' a new
file.
Please review this changeset to add the file; the content of the file
were previously reviewed as part of JDK-8224257.
JBS:
+1
Mandy
On 5/30/19 10:54 AM, Jonathan Gibbons wrote:
In creating the changeset for JDK-8224257, I forgot to 'hg add' a new
file.
Please review this changeset to add the file; the content of the file
were previously reviewed as part of JDK-8224257.
JBS:
In creating the changeset for JDK-8224257, I forgot to 'hg add' a new file.
Please review this changeset to add the file; the content of the file
were previously reviewed as part of JDK-8224257.
JBS: https://bugs.openjdk.java.net/browse/JDK-8225066
Webrev:
On 2019-05-30 08:32, Weijun Wang wrote:
On May 30, 2019, at 10:01 PM, Erik Joelsson wrote:
In my experience, using directories for dependencies in make does not work
well. Since all the files in make/data/cacerts are in a flat structure, I would
recommend expressing the prerequisites as:
> On May 30, 2019, at 10:01 PM, Erik Joelsson wrote:
>
> In my experience, using directories for dependencies in make does not work
> well. Since all the files in make/data/cacerts are in a flat structure, I
> would recommend expressing the prerequisites as:
>
> $(wildcard
Hello Max,
Looking in ToolsJdk.gmk, I realize that the BUILD_TOOLS variable was
renamed back when we unified the repositories and is now called
BUILD_TOOLS_JDK. It seems like I missed updating the references to this
variable in the gendata dir. If you use the new variable name in the
Jon:
Looks good to me as well.
Tim
On 05/30/19 06:27, Erik Joelsson wrote:
Looks good to me, but I also contributed the build changes.
/Erik
On 2019-05-29 15:44, Jonathan Gibbons wrote:
Please review a fix to provide a new build-time tool to fix up the
output generated by the "pandoc"
Since I need to track all added, removed, updated files in that directory, I
thought depending on the directory itself is more correct. If I use the
FindFiles function, then if some files are removed the cacerts will not be
rebuilt.
--Max
> On May 30, 2019, at 9:11 PM, David Holmes wrote:
>
Build change looks good.
/Erik
On 2019-05-30 04:44, Aleksey Shipilev wrote:
http://cr.openjdk.java.net/~shade/8225048/webrev.01/
Some history: Shenandoah used to support x86_32 in "passive" mode long time
ago. This mode relies
only on stop-the-world GC to avoid implementing barriers
Looks good to me, but I also contributed the build changes.
/Erik
On 2019-05-29 15:44, Jonathan Gibbons wrote:
Please review a fix to provide a new build-time tool to fix up the
output generated by the "pandoc" tool, which generates output that
fails to meet all of our documentation
Hi Max,
Not a review :)
On 30/05/2019 11:01 pm, Weijun Wang wrote:
Please take a review at
http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
Please pay attention to the 1st 3 and the last 2 files. Others are PEM files
for all certs inside the original cacerts.
There is one thing I
Please take a review at
http://cr.openjdk.java.net/~weijun/8193255/webrev.00/
Please pay attention to the 1st 3 and the last 2 files. Others are PEM files
for all certs inside the original cacerts.
There is one thing I cannot get correct. If I update the GenerateCacerts.java
file and rerun
The changes look good to me. Thanks!!
Roman
> http://cr.openjdk.java.net/~shade/8225048/webrev.01/
>
> Some history: Shenandoah used to support x86_32 in "passive" mode long time
> ago. This mode relies
> only on stop-the-world GC to avoid implementing barriers (basically, runs
> Degenerated
http://cr.openjdk.java.net/~shade/8225048/webrev.01/
Some history: Shenandoah used to support x86_32 in "passive" mode long time
ago. This mode relies
only on stop-the-world GC to avoid implementing barriers (basically, runs
Degenerated GC all the
time). It was an interesting mode to see the
Hi Moshe,
can you try running configure with --disable-precompiled-headers
Thanks,
David
On 30/05/2019 6:26 pm, Moshe Zuisman wrote:
Configuration summary:
The existing configuration has been successfully updated in
Configuration summary:
The existing configuration has been successfully updated in
/cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release
using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'.
Configuration
26 matches
Mail list logo
