On Thu, 2018-09-13 at 11:00 +1000, David Holmes wrote:
> Correction ...
>
> On 13/09/2018 8:31 AM, David Holmes wrote:
> > On 12/09/2018 6:16 PM, Severin Gehwolf wrote:
> > > On Wed, 2018-09-12 at 17:58 +1000, David Holmes wrote:
> > > > But I don't understand why the optimization setting is being
This is the last part of the mapfile cleanup. Two special libraries for
supporting dtrace on solaris was not converted before.
As before, I have verified that there is no unwanted symbol changes in
the resulting libraries.
(This fix also removes the libjsound mapfile once and for all -- the
The two build tools hasher and jarreorder is not used in the build
anymore and should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210704
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8210704-remove-hasher-and-jarreorder/webrev.01
/Magnus
Hi Erik,
On Wed, 2018-09-12 at 10:25 -0700, Erik Joelsson wrote:
> Hello,
>
> I very much doubt it was included with the new build system. We were
> extremely careful to use the exact same flags then, and did binary
> comparisons of all object files to verify equal builds.
>
> Tracing back, it
On 2018-09-13 10:35, Magnus Ihse Bursie wrote:
The two build tools hasher and jarreorder is not used in the build
anymore and should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210704
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8210704-remove-hasher-and-jarreorder/webrev.01
U
On 13/09/2018 09:46, Magnus Ihse Bursie wrote:
On 2018-09-13 10:35, Magnus Ihse Bursie wrote:
The two build tools hasher and jarreorder is not used in the build
anymore and should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210704
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-82
We regularly use the COMPARE_BUILD framework to test build
reproducability, by comparing two builds made directly after one
another. This test currently fails on solaris, since the compilation of
libfontmanager and libsaproc is not stable (and thus can produce
different disassembly each build).
Hi Erik,
On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote:
> Hello Severin,
>
> In configure, we now set FDLIBM_CFLAGS based on toolchain type and
> capabilities. In JvmOverrideFiles.gmk, the use of it is still
> conditional on Linux. I don't think it should be. We already have the
> con
Severin,
Your patch looks good to me. I'm assuming you have tested that nothing breaks.
/Magnus
> 13 sep. 2018 kl. 10:43 skrev Severin Gehwolf :
>
> Hi Erik,
>
>> On Wed, 2018-09-12 at 10:25 -0700, Erik Joelsson wrote:
>> Hello,
>>
>> I very much doubt it was included with the new build syst
On Windows, we compile two versions of libjli, one normal dynamic dll,
and one static library *). Then when we create our launchers, we link
with the normal, dynamic libjli for all launchers, except java.exe and
javaw.exe, which are linked with the static library.
The build system needs to do
On 13/09/2018 14:07, Magnus Ihse Bursie wrote:
:
Apparently, someone was trying to get rid of dll dependencies from
java.exe. Why that would be desirable it does not say. Neither why
this should not apply to all other launchers. (Perhaps there were not
that many in these days?)
Do anyone
Hi Magnus,
On Thu, 2018-09-13 at 13:52 +0200, Magnus Ihse Bursie wrote:
> Severin,
>
> Your patch looks good to me. I'm assuming you have tested that nothing
> breaks.
Thanks for the review!
Yes, I've tested with run-test-tier1 which seems OK. It includes
serviceability/sa/ClhsdbVmStructsDump
Hello,
Reading that bug, it seems the problem is when the installer copies
java.exe into the Windows system directory. In that case, it may not
have access to the msvcr re-distributables. I will try to find out if
our installers are still doing this.
/Erik
On 2018-09-13 06:32, Alan Bateman
Looks good to me. Thanks for cleaning this up!
/Erik
On 2018-09-13 08:06, Severin Gehwolf wrote:
Hi Magnus,
On Thu, 2018-09-13 at 13:52 +0200, Magnus Ihse Bursie wrote:
Severin,
Your patch looks good to me. I'm assuming you have tested that nothing breaks.
Thanks for the review!
Yes, I've
Looks ok to me.
/Erik
On 2018-09-13 01:00, Magnus Ihse Bursie wrote:
This is the last part of the mapfile cleanup. Two special libraries
for supporting dtrace on solaris was not converted before.
As before, I have verified that there is no unwanted symbol changes in
the resulting libraries.
Looks good.
/Erik
On 2018-09-13 01:46, Magnus Ihse Bursie wrote:
On 2018-09-13 10:35, Magnus Ihse Bursie wrote:
The two build tools hasher and jarreorder is not used in the build
anymore and should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210704
WebRev:
http://cr.openjdk.
Looks good.
/Erik
On 2018-09-13 02:23, Magnus Ihse Bursie wrote:
We regularly use the COMPARE_BUILD framework to test build
reproducability, by comparing two builds made directly after one
another. This test currently fails on solaris, since the compilation
of libfontmanager and libsaproc is
On 2018-09-13 03:02, Severin Gehwolf wrote:
Hi Erik,
On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote:
Hello Severin,
In configure, we now set FDLIBM_CFLAGS based on toolchain type and
capabilities. In JvmOverrideFiles.gmk, the use of it is still
conditional on Linux. I don't think it sh
Ditto, although as the "owner" of libfontmanager I am curious what
are the rare characteristics that make just these two libraries
"unstable" in this sense ?
-phil.
On 09/13/2018 10:24 AM, Erik Joelsson wrote:
Looks good.
/Erik
On 2018-09-13 02:23, Magnus Ihse Bursie wrote:
We regularly us
I believe it's because they are C++ instead of pure C. We always had a
harder time comparing C++ binaries.
/Erik
On 2018-09-13 10:48, Phil Race wrote:
Ditto, although as the "owner" of libfontmanager I am curious what
are the rare characteristics that make just these two libraries
"unstable"
On 9/13/18 1:46 AM, Magnus Ihse Bursie wrote:
On 2018-09-13 10:35, Magnus Ihse Bursie wrote:
The two build tools hasher and jarreorder is not used in the build
anymore and should be removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210704
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-
On 2018-09-13 19:58, Erik Joelsson wrote:
I believe it's because they are C++ instead of pure C. We always had a
harder time comparing C++ binaries.
Hm, is that so? You mean as in linking using TOOLCHAIN_LINK_CXX?
I'm just a bit "allergic" towards libfontmanager. There's a lot of odd
things ha
On 2018-09-12 19:33, naoto.s...@oracle.com wrote:
Hi Magnus, Erik,
Thank you for your comments. I updated the webrev according to your
suggestions:
http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
Looks good to me.
/Magnus
As to the duplicated "common" in the dependency, yes that'
When running e.g. Xcode 9.4 on macosx 10.12, the configure scripts fails
with: "Failed to determine Xcode version" This is not very helpful.
Adding the output of the failed xcodebuild call (typically something
like "Executable requires at least macOS 10.13, but is being run on
macOS 10.12.6, a
On 2018-09-12 18:35, Martin Buchholz wrote:
On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
wrote:
On 2018-09-05 20:59, Martin Buchholz wrote:
So ... Magnus, are you happy with the current state of the proposed patch?
I'm sorry Martin, but I can't figure out what the current state is. I t
On 2018-09-13 12:21, Magnus Ihse Bursie wrote:
On 2018-09-13 19:58, Erik Joelsson wrote:
I believe it's because they are C++ instead of pure C. We always had
a harder time comparing C++ binaries.
Hm, is that so? You mean as in linking using TOOLCHAIN_LINK_CXX?
More because there are C++ source
On 2018-09-13 21:59, Erik Joelsson wrote:
On 2018-09-13 12:21, Magnus Ihse Bursie wrote:
On 2018-09-13 19:58, Erik Joelsson wrote:
I believe it's because they are C++ instead of pure C. We always had
a harder time comparing C++ binaries.
Hm, is that so? You mean as in linking using TOOLCHAIN_L
On Thu, Sep 13, 2018 at 12:48 PM, Magnus Ihse Bursie
wrote:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch
>
> I'm not entirely happy, but it'll have to do. The problem here is that the
> underlying structure of the flags handling is still not good so this
> pr
Hi,
I'd like to get a review of an 8u backport of:
8202557: OpenJDK fails to start in Windows 7 and 8.1 after upgrading
compiler to VC 2017
https://bugs.openjdk.java.net/browse/JDK-8202557
11 change: http://hg.openjdk.java.net/jdk/jdk/rev/35b22ca681d1
11 review thread:
http://mail.openjdk.j
Looks good.
/Erik
On 2018-09-13 14:03, Kevin Walls wrote:
Hi,
I'd like to get a review of an 8u backport of:
8202557: OpenJDK fails to start in Windows 7 and 8.1 after upgrading
compiler to VC 2017
https://bugs.openjdk.java.net/browse/JDK-8202557
11 change: http://hg.openjdk.java.net/jdk/
We're not entirely happy either.
A much higher interface might look like
TRY_ADD_LINKER_FLAGS -z noexecstack
Agreed. I'm working towards a solution like that.
which would add -Wl,-z,noexecstack to LDFLAGS when appropriate
hmmm ...
I only just noticed that both gcc and clang accept simp
There's a bunch of interrelated smelly code regarding static libraries
on macosx.
I started by turning libfdlibm into a static library on macosx, as on
all other platforms. It turned out that we don't have proper support for
static libraries on macosx, so I fixed this too.
Secondly, I remove
The file make/langtools/tools/propertiesparser/PropertiesParser.java
b/make/langtools/tools/propertiesparser/PropertiesParser.java is used to
convert .properties files into .java files as part of the gensrc step.
However, due to it's use of creating it's output directly from HashMaps,
it's not
Looks okay to me.
Mandy
P.S. I cc'ed compiler-dev since I think you meant to cc compiler-dev
instead of hotspot-compiler-dev.
On 9/13/18 3:20 PM, Magnus Ihse Bursie wrote:
The file make/langtools/tools/propertiesparser/PropertiesParser.java
b/make/langtools/tools/propertiesparser/PropertiesPa
+1
-- Jon
On 09/13/2018 03:25 PM, mandy chung wrote:
Looks okay to me.
Mandy
P.S. I cc'ed compiler-dev since I think you meant to cc compiler-dev
instead of hotspot-compiler-dev.
On 9/13/18 3:20 PM, Magnus Ihse Bursie wrote:
The file make/langtools/tools/propertiesparser/PropertiesParser.ja
Hello,
Nice cleanup overall.
In CoreLibraries.gmk: I don't think it's safe to use $(BUILD_LIBFDLIB)
directly as input to LIBS. That variable may contain other targets as
well (such as debug symbol files and soon compile_commands.js snippets).
A safer variable to use is $(BUILD_FDLIBM_TARGET).
I checked and the copying of java.exe was done in the now legacy jre
installer, so from what I can tell, there is no longer a need for static
linking.
/Erik
On 2018-09-13 09:14, Erik Joelsson wrote:
Hello,
Reading that bug, it seems the problem is when the installer copies
java.exe into th
Hello,
Looks good. Perhaps add a comment explaining why the otherwise unusual
choice of collection class is used.
/Erik
On 2018-09-13 15:20, Magnus Ihse Bursie wrote:
The file make/langtools/tools/propertiesparser/PropertiesParser.java
b/make/langtools/tools/propertiesparser/PropertiesParser
Hello Severin,
On 09/12/2018 04:48 AM, Severin Gehwolf wrote:
Hi David,
On Wed, 2018-09-12 at 13:57 +1000, David Holmes wrote:
Hi Severin,
Sorry I'm a bit confused now.
Originally for ppc/s390x/aarch64 the optimization level for fdlibm was
HIGH. But now it will be LOW due to:
45 ifneq (
Hi Andrew,
Thanks for your kind response!
在 2018年09月11日 01:19, Andrew Hughes 写道:
On Wed, 5 Sep 2018 at 10:52, Leslie Zhai wrote:
Hi Andrew,
Thanks for your response!
I just quote it from here:
http://mail.openjdk.java.net/pipermail/build-dev/2016-July/017464.html
I spotted that jsig is j
Hi Zhengyu,
Thanks for your patch! I will backport it to jdk8u and test it for X86
and mips64el.
Thanks,
Leslie Zhai
在 2018年09月12日 20:58, Zhengyu Gu 写道:
Probably should also backport the followup RFE:
https://bugs.openjdk.java.net/browse/JDK-8206183
Thanks,
-Zhengyu
On 09/11/2018 10:5
41 matches
Mail list logo
