ook at it, it might be easier to have a smaller set
>of VS releases to support.
On the other hand, having VS2017 for JDK11 - head is rather nice for
backporting .
Best regards, Matthias
-Original Message-
From: Alan Bateman
Sent: Tuesday, 10 May 2022 13:16
To: Baesken, Matthias ;
Hi Aleksey I did not use a devkit, just installed gcc/g++ on the Alpine
docker image I used .
Maybe that's why I do not see this help output you added ?
Best regards, Matthias
>> Hi , while attempting to build jdk on an Alpine Linux I was running into the
>> following issue :
>> After some
Sent: Montag, 17. Januar 2022 01:31
To: Baesken, Matthias
Cc: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net'
; Andrew Brygin ; Yuri Nesterenko
; Zeller, Arno
Subject: Re: Heads up: planned Harfbuzz update in jdk11u-dev
* PGP Signed by an unknown key
On 09:19 Fri 14 Jan , B
>It sounds like a bug that should get fixed. :)
>
>Let me just verify that I understand this correctly. Your specified
>devkit is used to actually compile the JDK, it's just in the configure
>script output that things look wrong? (I suspect this will also mess up
>version checking for clang in
Hello, I noticed the following when building jdk on macOS 10.14 with xcode12
devkit .
The tool "xcodebuild" which is used at some places in the configure process
(see basic.m4 / toolchain.m4) fails because of the too old macOS :
configure:70788: xcodebuild output: dyld: Library not
> Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m.
Hi Paul, did that :
https://bugs.openjdk.java.net/browse/JDK-8253791
https://github.com/openjdk/jdk/pull/403
Best regards, Matthias
-Original Message-
From: Hohensee, Paul
Sent: Dienstag, 29.
.
Best regards, Matthias
-Original Message-
From: Yasumasa Suenaga
Sent: Donnerstag, 13. August 2020 06:15
To: David Holmes ; Baesken, Matthias
; hotspot-runtime-...@openjdk.java.net;
build-dev@openjdk.java.net
Cc: Doerr, Martin
Subject: Re: PING: RFR: 8250598: Hyper-V is
>I understand that if the process runs on Xen on other hypervisor (e.g. KVM),
>information for Xen would be set between 0x4100 and 0x4001.
>Ok, I will not remove the loop in new webrev, and will add comment about it.
Hi Yasumasa , thanks !
Regarding the WMI overhead , if you could get
Hi Yasumasa , I'm more or less fine with the change .
But still not fully convinced that removing the iteration is a good thing .
http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/webrev.01/src/hotspot/cpu/x86/vm_version_x86.cpp.frames.html
1827 for (base = 0x4000; base < 0x4001;
HI David and Martin, thanks for the reviews !
>
>Hi Matthias,
>
>Looks good. Thanks for fixing it.
>
>Best regards,
>Martin
>>
>> Hi Matthias,
>>
>> That all seems fine to me.
>>
>> David
>>
Hello, please review this small patch that fixes the ppc64(le) and s390x
builds .
( They started to break since the 24th June, looks like some inclusions were
missing after recent HS changes )
Bug/webrev :
https://bugs.openjdk.java.net/browse/JDK-8248334
Reviewed !
Best regards, Matthias
>thank you for proposing a fix which allows building with old awk on AIX. Works
>fine.
>
>Here's the webrev:
>http://cr.openjdk.java.net/~mdoerr/8244756_AIX_fix_awk_expr/webrev.00/
>
Thanks for the review !
-Original Message-
From: Erik Joelsson
Sent: Donnerstag, 2. April 2020 15:31
To: Baesken, Matthias ;
'hotspot-...@openjdk.java.net' ;
'build-dev@openjdk.java.net'
Subject: Re: RFR: 8241996: on linux set full relro in the linker flags
Looks good to me.
/Erik
Hi Erik, that's a good point .
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8241996.1/
Best regards, Matthias
> Hello Matthias,
>
> We are currently setting -z now for slowdebug builds. That should be
> removed if it's now set by default for all configs.
Hello, please review this binary hardening related change.
To improve binary hardening, we should enable full relro in the OpenJDK builds.
Currently
our build settings enable only partial relro (they miss z,now).
See
Hello, please review this small downport of 8201349 .
Reason is that we run into warnings as errors, when building jdk11 on Linux
with gcc-7.X and with-zlib=bundled .
This adds the compiler options
-Wno-unused-function -Wno-implicit-fallthrough
To some compilations e.g. zlib-files ;
Hello, we were running into build errors recently when using gcc-7 and
with-zlib=bundledin jdk11u-dev .
This combination worked nicely in jdk/jdk .
Reason is that in jdk11 we do not have :
8201349: build broken when configured with --with-zlib=bundled on gcc 7.3
Hello, in the combination minimal+server , you can jlink smaller target
images using "minimal" because of the much smaller libjvm.so .
Just an example , target image size is sometimes important too .
Best regards, Matthias
> I am just wondering, what are the practical reasons for
karound, but not a real
replacement to what we have currently .
Best Regards, Matthias
>
> On 2020-02-19 16:59, Baesken, Matthias wrote:
> > Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm-
> variants=minimal,server" in our central b
Hi Magnus, yes we do. We build (on Linux only currently)
"--with-jvm-variants=minimal,server" in our central builds to test that
minimal is still working and that is was not destroyed by recent changes .
Best Regards, Matthias
>
> Message: 2
> Date: Wed, 19 Feb 2020 13:26:35 +0100
>
> > Hello , please review the downport of "8234525: enable link-time section-
> gc for linux s390x to remove unused code" to jdk11 .
> >
> > My change from jdk/jdk did not apply directly and I had to adjust it
> > slightly .
> >
> >
> >
> >
> > Bug and jdk/jdk change :
> >
> >
Ping - any reviews ?
Thanks, Matthias
From: Baesken, Matthias
Sent: Dienstag, 11. Februar 2020 10:24
To: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net'
Subject: RFR [jdk11]: 8234525: enable link-time section-gc for linux s390x to
remove unused code
Hello , please review
Hello , please review the downport of "8234525: enable link-time section-gc
for linux s390x to remove unused code" to jdk11 .
My change from jdk/jdk did not apply directly and I had to adjust it slightly .
Bug and jdk/jdk change :
https://bugs.openjdk.java.net/browse/JDK-8234525
option as it's all orthogonal to the
> main debug symbols file creation.
> > * The code need to make sure to separate stripped.pdb and normal pdb
> > files, when enabled.
> >
> > * And there must not be a heavy penalty in added code complexity.
> >
> /Erik
> >
Hi Clas / Magnus, thanks for the reviews !
Best regards, Matthias
>
>
> On 2020-02-05 11:43, Magnus Ihse Bursie wrote:
> > I'm fine with the fix.
>
> Me too, looks good and more consistent.
>
> /Claes
mal), true)
).
But we built those files in the normal/regular productive make already with
-O3, and this works fine so I would not see any issues here ...
Best regards , Matthias
>
> On 2020-02-05 10:49, Baesken, Matthias wrote:
> > Hello, please review this small change .
> >
Hello, please review this small change .
The OPT_SPEED_SRC list (for files to be built optimized for speed) in
JVMFeatures.gmk includes a few files with cpu-dependend names for arm
but misses the corresponding files for other cpus (e.g. frame_arm.cpp). The
change adds those files .
Hi Magnus, looks good to me !
> Date: Tue, 4 Feb 2020 22:48:07 +0100
> From: Magnus Ihse Bursie
> To: build-dev@openjdk.java.net, hotspot-dev
>
> Subject: Re: RFR: JDK-8238281 Raise minimum gcc version needed to 5.0
> Message-ID:
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi Erik, maybe we can just rename the configure option to
>
> --enable-stripped-pdbs-for-bundle
>
> AND make the default = no/false .
> Then without setting the configure flag, everything stays as it is for JDK
> vendors/distributors who do not want the stripped pdbs in the bundle.
;--enable-stripped-pdbs-for-bundle" is set to yes , one with one without
stripped pdbs .
Best regards, Matthias
>
> On 2020-01-23 00:03, Baesken, Matthias wrote:
> > Hi Erik, yes true sorry for answering your comments a bit late .
> >
> >> If a user runs j
Thanks for the review !
Erik, are you fine with the latest change too ?
Best regards, Matthias
> On 2020-01-24 10:27, Baesken, Matthias wrote:
> > Hi Erik, thanks for the comments, new webrev :
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.7/
>
.
>
> jdk-options.m4
>
> The default is now true for all platforms. I would suggest moving the
> s390x conditional down into an elif after the elif for "no".
>
> LibCommon.gmk
>
> Please revert whole file.
>
> /Erik
>
> On 2020-01-23 05:15, Baesken, Matthia
t;
> /Erik
>
>
> On 2020-01-22 05:33, Baesken, Matthias wrote:
> > Hi Magnus / David, here is a new webrev :
> >
> >
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8236714.4/
> >
> >
> > it supports now a configure switch
limited experience , the developers do not work with the bundles (that
would contain now after my patch the stripped pds) but with a "normal" jdk
image that is created my make all.
Best regards, Matthias
>
> This still does not address anything in my objection.
>
Hi Erik, okay I'll check that .
I had the impression I would have ordering issues of the m4 files and how they
end up in the generated-configure.sh but looks like that’s not the case .
Best regards, Matthias
>
> Hello Matthias,
>
> You can keep the setting up of all the flags in
Hello, here is an updated version :
http://cr.openjdk.java.net/~mbaesken/webrevs/8237192.3/
this one supports a configure switch "--enable-stripped-pdbs"to enable the
feature .
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent: D
(and keep
it enabled always for LIB_JVM).
Best regards, Matthias
From: Baesken, Matthias
Sent: Freitag, 17. Januar 2020 12:44
To: Magnus Ihse Bursie ; David Holmes
; 'build-dev@openjdk.java.net'
; 'hotspot-...@openjdk.java.net'
Subject: RE: RFR: 8236714: enable link-time section-gc for linux
Hi Erik, new webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8237374.1/
Best regards, Matthias
-Original Message-
From: Erik Joelsson
Sent: Freitag, 17. Januar 2020 15:18
To: Baesken, Matthias ; 'build-dev@openjdk.java.net'
; 'hotspot-...@openjdk.java.net'
Subject: Re: RFR
here can be non-technical issues relating to shipping symbol files in a
> product.
>
> Thanks,
> David
>
> On 17/01/2020 6:44 pm, Baesken, Matthias wrote:
> > Hello, please review this change related to stripped/"public" pdb file
> generation on Windows .
> >
On 2020-01-16 10:30, David Holmes wrote:
Hi Matthias,
On 16/01/2020 6:10 pm, Baesken, Matthias wrote:
Hi David, sure we can introduce a way to switch this on/off.
Thanks.
There is already something similar for the link-time optimization (flto) , see
the feature
JvmFeatures.gmk
180 ifeq ($(call
09:44, Baesken, Matthias wrote:
Hello, please review this change related to stripped/"public" pdb file
generation on Windows .
Currently the JDK bundle on Windows does not contain pdb files (full pdb files
are in a separate symbols bundle).
This leads currently to bad native stack
Hello, please review this change related to stripped/"public" pdb file
generation on Windows .
Currently the JDK bundle on Windows does not contain pdb files (full pdb files
are in a separate symbols bundle).
This leads currently to bad native stack traces e.g. when crashes occur.
One reason
Hello, please review this small patch .
When building 2 VM variants minimal and server in one build and using
--with-jvm-variants=minimal,server
to configure this setup , the build works nicely. But I notice that in the
server VM, cds is removed.
Instead of
checking if cds should be
Hello, please review this very small change .
It removes file that are not present any more from the OPT_SPEED_SRC file list
in JvmFeatures.gmk .
( this is a list of files to be optimized for speed when we otherwise optimize
for size in the minimal-JVM build)
Bug/webrev :
d any multi JVM configs regularly, so things like this falls through
> the cracks.
>
> /Erik
>
> On 2020-01-16 02:18, Baesken, Matthias wrote:
> > Hello, I noticed the following strange "feature" (or is it a bug?) .
> > When building 2 VM variants in one build
Hello, I noticed the following strange "feature" (or is it a bug?) .
When building 2 VM variants in one build and using
--with-jvm-variants=minimal,server
For this, the build works nicely. But I notice that in the server VM, cds is
removed.
Instead of
checking if cds should be
Hi David, sure we can introduce a way to switch this on/off.
There is already something similar for the link-time optimization (flto) , see
the feature
JvmFeatures.gmk
180 ifeq ($(call check-jvm-feature, link-time-opt), true)
190 ifeq ($(call check-jvm-feature, link-time-opt), false)
Hi Erik, I did not notice slowdowns in our night makes .
Looking at a specific test machine I use (x86_64, build JOBS hardwired set
to 12 ) I get around 6 minutes build time with and without the feature .
( but you have to take into account that the link-time section-gc on
e with LTO/gold
and know if gold could maybe improve linking times with LTO?
[1] https://gcc.gnu.org/wiki/LinkTimeOptimization
[2] https://stackoverflow.com/questions/31688069/requirements-to-use-flto
Baesken, Matthias mailto:matthias.baes...@sap.com>>
schrieb am Mi., 15. Jan. 2020, 07:02:
He
Hello, I used the "normal" linker so I think what
https://stackoverflow.com/questions/31688069/requirements-to-use-flto
says is true , one can use also the "normal" linker .
Haven't checked for any performance (or other) improvements when using gold
instead .
Best regards,
20 14:40
To: Aleksei Voitylov
Cc: Baesken, Matthias ; Magnus Ihse Bursie
; serviceability-...@openjdk.java.net; build-dev
; hotspot-...@openjdk.java.net
Subject: Re: serviceability agent : problems when using gcc LTO (link time
optimization)
While we are speaking about all the drawbacks of LTO, it's s
;
> On 2020-01-14 06:07, Baesken, Matthias wrote:
> > Hello, the following change enables the link-time section-gc for linux .
> >
> > gcc and ld support enabling "garbage collection" of unused input sections.
> > This can be used to eliminate unused coding
Hello Magnus and Aleksei, thanks for the input .
The times you provided really look like they make a big difference at least
for people often building minimal-vm .
Guess I have to measure myself a bit (maybe the difference is not that big on
our linux s390x / ppc64(le) ) .
>
> If the
Hello, the following change enables the link-time section-gc for linux .
gcc and ld support enabling "garbage collection" of unused input sections.
This can be used to eliminate unused coding from native libraries (especially
when already compiling the objects with compiler flags
).
Best regards, Matthias
On 2020-01-10 11:01, Baesken, Matthias wrote:
Hello, I recently looked into the gcc lto optimization mode (see for some
details https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html and
http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter
Thanks for the reviews !
Best regards, Matthias
>
> Hi,
>
> I don't think another review is needed, but FWIW this looks good to
> me!
>
> /Claes
>
> On 2019-12-20 11:03, Baesken, Matthias wrote:
> > Hi Erik, thanks for the review ! I'll remove the
.
> Documenting it in the JBS issue is enough.
>
> Thanks for cleaning this up!
>
> /Erik
>
> On 2019-12-20 09:37, Baesken, Matthias wrote:
> > Hello, please review this small MSVC related change .
> >
> > The MSVC based builds still have the old flag
Hello, please review this small MSVC related change .
The MSVC based builds still have the old flag -d2Zi+ set; this is an
undocumented flag , the name of the flag for enhanced optimized debugging is
since VS2013 -Zo .
However the flag (-Zo) is enabled by default for a long time , so the
Hello, please review the jdk11 downport of 8234809 .
The patch form jdk/jdk did not apply directly so
make/autoconf/flags-ldflags.m4 had to be adjusted a little bit for jdk11 .
Original discussion :
https://mail.openjdk.java.net/pipermail/build-dev/2019-November/026347.html
+
is the goal. Even if the tests show that Os/O2 is no
different than O3,
* who knows if this will be true in the future.
*
What alternatives do you have in mind ?
Best regards, Matthias
From: August Nagro
Sent: Mittwoch, 18. Dezember 2019 14:42
To: Baesken, Matthias
Cc: claes.redes
Hi August , thanks for pointing to your webpage, very interesting !
We did our builds+tests/benchmarks with gcc 7.4.0 , what compiler+version
did you use?
Probably I should look a bit more into Dacapo (we used that one in the past too
sometimes).
Best regards, Matthias
>
> I
Hello, a small update from my side . I had (on Linux) for a couple of days
our jdk11u tests + benchmarks running with -Os instead of the usual
settings (-O3) .
With have (independent of -Os / -O3) a bit of variance in our benchmarks
( jbb15 , jvm2008, jvm98 ) .
However the
Hello Martin, I checked building libjvm.so with -Os (instead of -O3) .
I used gcc-7 on linux x86_64 .
The size of libjvm.so dropped from24M (normal night make with -O3)
to 18M ( test make with -Os) .
(adding the link-time gc might reduce the size by another ~ 10 % ,
Thanks !
Florian, may I add you as reviewer ?
Best regards, Matthias
> Looks good.
>
> /Erik
>
> On 2019-11-26 05:07, Baesken, Matthias wrote:
> >> Hello Erik, Florian , currently relro is set already for libjvm.
> >> I think if this works nicely for
t; with-extra-ldflags .
>
>
> Best regards, Matthias
>
>
> > Hello,
> >
> > I wasn't directly involved in introducing these flags, but my
> > understanding is that it's always a performance compromise. I would
> > involve at least hotspot-dev for a
Hi Martin ,
> Hi Matthias and Erik,
>
> I also think this is an interesting option.
>
> I like the idea to generate smaller libraries. In addition to that, I could
> also
> imagine building with -Os (size optimized) by default and only select -O3 for
> performance critical files (e.g. C2's
Thanks for the update on this .
Do you plan to push it today or tomorrow ?
Best regards, Matthias
> -Original Message-
> From: Prasanta Sadhukhan
> Sent: Dienstag, 26. November 2019 10:26
> To: Baesken, Matthias ; Erik Joelsson
> ; 'build-dev@openjdk.java.net' d...@o
ldflags .
Best regards, Matthias
> Hello,
>
> I wasn't directly involved in introducing these flags, but my
> understanding is that it's always a performance compromise. I would
> involve at least hotspot-dev for a wider discussion on this as libjvm is
> the most affected lib
ias
>
> If there is a simple fix, I would very much like to see it done. I'm not
> familiar enough with this area to know what the implications would be
> though.
>
> /Erik
>
> On 2019-11-25 04:48, Baesken, Matthias wrote:
> > Hello, any comments on the issue ?
> &g
Hello, I wonder why the binary hardening on linux using Relocation
Read-Only (relro) is not enabled by default.
Some info can be found here :
https://wiki.debian.org/Hardening
https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro
Currently I notice
Hello, any comments on the issue ?
Could we maybe switch from using
NSTextInputSourceIdentifier
to
String (NSString* ?) , because
https://developer.apple.com/documentation/appkit/nstextinputsourceidentifier
says NSTextInputSourceIdentifieris a typealias for String ?
Best
ssume
> that makes the build quite chatty.
>
> /Erik
>
> On 2019-11-21 00:54, Baesken, Matthias wrote:
> > Hello,
> >
> > gcc and ld can be instructed to work together to "garbage collect" unused
> input sections.
> > This feature eliminates unused
Hello, I noticed that since today our jdk/jdk build fails on macOS . We run
it on macOS 10.12 .
It seems
https://hg.openjdk.java.net/jdk/jdk/rev/d0bfaae2ff33
8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores
system settings
Brought a dependency on 10.13. Was
Hello,
gcc and ld can be instructed to work together to "garbage collect" unused input
sections.
This feature eliminates unused code from native libraries. As a prerequisite to
take full advantage of the feature,
the source files need to be compiled with "-ffunction-sections -fdata-sections".
Thanks for the reviews !
> One minor thing: do you really want to keep the old code (as comment) in
> sharedRuntime_ppc.cpp:2853?
I remove it .
Best regards, Matthias
> -Original Message-
> From: Schmidt, Lutz
> Sent: Freitag, 1. November 2019 15:11
> To: Baesken
Hello, please review the following small AIX related fix.
It is a JDK11 only change , and fixes issues when building JDK11 with
xlc16/legacy xlc .
Currently the product build of jdk11 already works with xlc16 ; however
without this change , the (fast)debug build still fails
because
Thanks .
May I have a second review please ?
Best regards, Matthias
From: Doerr, Martin
Sent: Dienstag, 29. Oktober 2019 13:48
To: Baesken, Matthias ;
'hotspot-...@openjdk.java.net'
Cc: 'build-dev@openjdk.java.net'
Subject: RE: RFR: 8233078 : fix minimal VM build on Linux ppc64(le)
Hi
e, looks good to me.
Thanks,
Martin
From: Baesken, Matthias
mailto:matthias.baes...@sap.com>>
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-...@openjdk.java.net'
mailto:hotspot-...@openjdk.java.net>>
Cc: 'build-dev@openjdk.java.net'
mailto:build-dev@openjdk.java.net>&g
Hello, please review the following fix .
I recently experimented a bit with the minimal VM build on linux x86_64
(--with-jvm-features=minimal --with-jvm-variants=minimal) .
This worked fine .
However when I tried the minimal vm build on linux ppc64 / ppc64le , I
noticed that it
Hello, please review this small AIX related change .
I noticed that configure does not recognize AIX tar correctly . This leads
in the jdk/jdk AIX - build to a message :
checking what type of tar was found...
(without an info about the found tar )
Also the flag setting for aix tar is
ed for 2019
>
> - in globalDefinitions_xlc.hpp this comment seems no longer necessary
>
>// __IBMCPP__ is not defined any more with xlclang++
>
> But that said, if __IBMCPP__ is no longer defined then it seems a fix is
> needed in ./share/runtime/vm_version.cpp as well.
>
Thanks for the review !
May I have a second reviewer please?
Best regards, Matthias
> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 22. Juli 2019 12:43
> To: Baesken, Matthias ; Baesken, Matthias
> ; 'build-dev@openjdk.java.net' d...@openjdk.java.net&
Hello, any comments please ?
From: ppc-aix-port-dev On Behalf Of
Baesken, Matthias
Sent: Freitag, 19. Juli 2019 12:20
To: 'build-dev@openjdk.java.net' ;
'ppc-aix-port-...@openjdk.java.net'
Subject: [CAUTION] RFR: 8228426: xlc: switch to clang-style warning disabling
Please review
Please review the following change that switches to clang-style warning
disabling on AIX, and adjusts the warning disabling to current needs .
Recently the jdk/jdk build on AIX switched to xlc16/xlclang.
This means we can now use the standard clang-style warning disabling (the old
legacy
t; Best regards
> Christoph
>
> > -Original Message-
> > From: build-dev On Behalf Of
> > Baesken, Matthias
> > Sent: Dienstag, 16. Juli 2019 16:40
> > To: 'build-dev@openjdk.java.net'
> > Subject: [CAUTION] build.log: Output from failing command(s)
Hello, In case of JVM crashes in the build (yes they happen in development
) , we print some info about the crash at the end of the build log file
In the Output from failing command(s) repeated here … section .
This looks like the following (from a recent crash on AIX ) :
===
en/webrevs/8227389.0/
Thanks and best regards, Matthias
I think this is fine for 14.
Cheers, Thomas
On Mon, Jul 8, 2019 at 9:23 AM Baesken, Matthias
mailto:matthias.baes...@sap.com>> wrote:
Hello, when building jdk/jdk on AIX (using the current default xlc16) I
get a ton of warni
Hello, when building jdk/jdk on AIX (using the current default xlc16) I
get a ton of warnings :
warning: 1540-5200 The option "langlvl=c99vla" is not supported.
warning: 1540-5200 The option "langlvl=noredefmac" is not supported.
The 2 options seem to be gone with the current xlc16
Hello, any more reviews ?
May I push the change ?
Best regards, Matthias
From: Thomas Stüfe
Sent: Mittwoch, 3. Juli 2019 14:09
To: Baesken, Matthias
Cc: build-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR: [XS] 8227171: provide function names in native stack trace
Thanks for the review !
From: Thomas Stüfe
Sent: Mittwoch, 3. Juli 2019 14:09
To: Baesken, Matthias
Cc: build-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
Subject: Re: RFR: [XS] 8227171: provide function names in native stack trace on
aix with xlc16
Looks good and trivial. Thanks
Hello please review this small fix for AIX (needed with the new xlc16) .
Currently we miss function names in the hs_err file :
0x000115098660 - 0x09000f629a4c libjvm.so::+0x6c
(C++ saves_lr stores_bc gpr_saved:4 )
0x0001150986f0 - 0x0900113594bc libjvm.so::+0x95c
(C++
Hello please review this small fix for a compile issue on OSX .
Today I compiled jdk/jdk on a machine with XCode 10.2 . It worked
pretty well .
However this small issue showed up .
In file included from
ree_On-Device_Development)
XCode 8 and higher come with at least MacOSX SDK 10.12 .
So checking for the Xcode version might make more sense .
Best regards, Matthias
> -Original Message-
> From: Erik Joelsson
> Sent: Mittwoch, 19. Juni 2019 19:30
> To: Baesken, Matt
>&1 | $HEAD -n 1`
( or use the sw_vers command and check the output
sw_vers -productVersion
10.12.6
)
What do you think ?
Best regards, Matthias
From: Baesken, Matthias
Sent: Mittwoch, 19. Juni 2019 09:51
To: 'build-dev@openjdk.java.net'
Cc: Schuenemann, Rene
Subject: jdk/jdk (+jdk12)
Hello, I noticed that we fail on OSX 10.11 in the build . Reason is that
NSWindowStyleMaskDocModalWindow is used since :
https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189
8208543: [macos] Support for apple.awt.documentModalSheet incomplete
Which is 10.12+ functionality . See
> -Original Message-
> From: Alan Bateman
> Sent: Freitag, 17. Mai 2019 09:47
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net'
> Subject: Re: zlib configuration : system vs. bundled
>
> On 16/05/2019 15:18, Baesken, Matthias wrote:
> > Hello Alan
le ),
People would need to patch the JDK .
At least we have the freedom to choose with the configure-flags .
Best regards, Matthias
> On 15/05/2019 09:16, Baesken, Matthias wrote:
> > Hi Alan, thanks for pointing me at the old discussion .
> >
> > http://mail.openjdk.java
Hello, the updated webrev is here :
http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.1/
Best regards, Matthias
>
>
> On 2019-05-15 01:16, Baesken, Matthias wrote:
> > Hi Alan, thanks for pointing me at the old discussion .
> >
> > http://mail.openjdk.j
Btw I adjusted the build docu and some m4 file comments regarding the zlib
usage :
https://bugs.openjdk.java.net/browse/JDK-8223944
http://cr.openjdk.java.net/~mbaesken/webrevs/8223944.0/
Best regards, Matthias
> -Original Message-
> From: Baesken, Matthias
> Sent:
ption in these arguments. (The default is `bundled`)."
Btw how is building.html generated , is this coming from building.md ?
Best regards, Matthias
> -Original Message-
> From: Alan Bateman
> Sent: Dienstag, 14. Mai 2019 17:47
> To: Baesken,
1 - 100 of 266 matches
Mail list logo
