Hi Martin,
looks good. I also verified that it removes the warning messages in the build.
Approved.
Best regards
Christoph
From: Doerr, Martin
Sent: Donnerstag, 14. Januar 2021 17:50
To: [email protected]; [email protected]
Cc: Lindenmaier, Goetz ; Langer, Christoph
Hi Andrew, all,
> On 09:19 Fri 14 Jan , Baesken, Matthias wrote:
> > For one of the next jdk11 updates, an update to a more recent harfbuzz
> version is planned.
> >
> > However the new harfbuzz 2.7.2 / 2.8.0 updates need C++11 support (they
> are built with option -std=c++11).
> > So please c
Hi Andrew,
> > > One dummy question:
> > > Why do we need to specify the real package name here?
> > > If we install gcc-10, I think apt system will pick up the latest gcc-10
> > > for us.
> >
> > IIRC the intent is to keep control over the gcc version and not
> > randomly update whenever the dis
the environment I think that also the ubuntu container that
is used is updated from time to time for certain patches and we usually don't
recognize it.
Best regards
Christoph
> -Original Message-
> From: Magnus Ihse Bursie
> Sent: Mittwoch, 13. April 2022 12:58
> To:
Hi,
that's because the PR is a based on a pre-loom version of master.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of Philip Race
> Sent: Montag, 23. Mai 2022 17:14
> To: Aleksey Shipilev ; Ioi Lam ;
> [email protected]
> Subject: Re: pre-submit tests
Hi,
I see the same on my windows build. I verified that 8.3 filenames are enabled.
I took a little closer look. In my PATH env in Cygwin I have:
...:/cygdrive/c/Program Files/Git/cmd:...
The git path is resolved via UTIL_LOOKUP_PROGS(GIT, git) in basic_tools.m4.
UTIL_LOOKUP_PROGS, defined in u
Hi Gary,
I was having a look at your changes.
I'm wondering what the reason is behind uncommenting WSASendDisconnect in
Java_sun_nio_ch_SocketDispatcher_preClose0 of file SocketDispatcher.c? And in
dbgsysSocketClose?
In socketTransport.c, line:
331 setLastError(0, "gethostb
But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it?
I still don't see the reason...
-Original Message-
From: [email protected] [mailto:[email protected]]
Sent: Donnerstag, 1. Februar 2018 12:17
To: Langer, Christoph ; OpenJDK Serviceability
Hi Gary,
> Here's a revised webrev
>
>http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html
>
> Still testing ...
>
> Using shutdown() fixed problems reported by the
> java/nio/channelSocketChannel tests.
The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysP
Cc: Langer, Christoph ; OpenJDK Serviceability
; OpenJDK Build
; OpenJDK Networking
Subject: Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996:
'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
One more to fix to cover the remaining test failures I was seeing.
Previou
Looks good, Chris.
> -Original Message-
> From: build-dev [mailto:[email protected]] On Behalf Of
> Chris Plummer
> Sent: Freitag, 23. Februar 2018 02:04
> To: [email protected] build-dev ;
> serviceability-dev
> Subject: RFR(S): 8196992: Resolve disabled warning
Looks good, Chris.
> -Original Message-
> From: core-libs-dev [mailto:[email protected]] On
> Behalf Of Chris Hegarty
> Sent: Mittwoch, 14. März 2018 13:57
> To: build-dev ; Core-Libs-Dev [email protected]>
> Subject: RFR 8199464 [11] Remove remaining vestiges of
Hi Matthias,
looks good to me, too.
Best regards
Christoph
From: Baesken, Matthias
Sent: Dienstag, 27. März 2018 09:23
To: Thomas Stüfe
Cc: [email protected]; [email protected]; Simonis, Volker
; Doerr, Martin ; Langer,
Christoph
Subject: RE: 8200246 : AIX build fails
Hi Bhaktavatsal,
As per [1], the jdk-hs repo will be closed tomorrow and finally merged with
jdk. After that, only the jdk depot will continue to be active and you should
not run into such type of inconsistencies any longer...
Best regards
Christoph
[1] http://mail.openjdk.java.net/pipermail/j
Hi Volker,
looks good.
Best regards
Christoph
> -Original Message-
> From: awt-dev [mailto:[email protected]] On Behalf Of
> Volker Simonis
> Sent: Freitag, 13. April 2018 15:29
> To: awt-dev ; build-dev [email protected]>
> Subject: RFR(XS): 8201524: [AIX] Don't lin
?
Best regards
Christoph
From: Baesken, Matthias
Sent: Donnerstag, 26. April 2018 16:14
To: '[email protected]' ;
[email protected]; [email protected]
Cc: Langer, Christoph ; Simonis, Volker
Subject: RFR : 8202322: AIX: symbol visibility flags not s
move the flag as you found that it is not
> supported in XLC < 13. And with XLC 13, it require more work to use this flag.
> >>
> >> Thanks,
> >> Bhaktavatsal Reddy
> >>
> >>
> >>
> >> -"Baesken, Matthias" wrote: ---
mail.com]
> Sent: Freitag, 27. April 2018 09:21
> To: Langer, Christoph
> Cc: Volker Simonis ; Baesken, Matthias
> ; Simonis, Volker ;
> [email protected]; [email protected]; build-
> [email protected]
> Subject: Re: RFR : 8202322: AIX: symbol visibi
Hi,
please help reviewing the contribution of the support for the AIX Input Method
Editor (IME) in AWT's Input Method Framework.
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/
Bug: https://bugs.openjdk.java.net/browse/JDK-8201429
I took Ichiroh's initial proposal [1] and tried t
le.com]
> Sent: Freitag, 4. Mai 2018 17:45
> To: Langer, Christoph ; awt-
> [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT
> Input Method Framework (IMF)
>
> Hell
Hi Alexey,
looks good to me. Symbols don't seem to be needed outside libzip (java.base).
Best regards
Christoph
> -Original Message-
> From: build-dev [mailto:[email protected]] On Behalf Of
> Alexey Ivanov
> Sent: Mittwoch, 9. Mai 2018 16:35
> To: core-libs ; hotspot-de
Hi Alexey,
good catch, I missed that.
Best regards
Christoph
> -Original Message-
> From: Alexey Ivanov [mailto:[email protected]]
> Sent: Freitag, 11. Mai 2018 13:21
> To: Langer, Christoph ; core-libs [email protected]>; hotspot-dev ;
> build-dev ;
Hi Matthias,
yes, reviewed.
Best regards
Christoph
From: Baesken, Matthias
Sent: Mittwoch, 16. Mai 2018 09:06
To: Langer, Christoph ; '[email protected]'
; [email protected];
[email protected]
Cc: Lindenmaier, Goetz
Subject: RE: RFR : 82
Hi all,
Here is an updated webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/
Can someone from the graphics/awt team please have a look at that change?
Especially checking that we don't break non-AIX platforms? Thanks in advance.
@Ichiroh: Thanks for your review and tests. Adressing
Christoph
> -Original Message-
> From: Philip Race [mailto:[email protected]]
> Sent: Sonntag, 20. Mai 2018 01:53
> To: Langer, Christoph
> Cc: [email protected]; Ichiroh Takiguchi
> ; [email protected]; ppc-aix-port-
> [email protected]
> Subject: Re
T does not
expand to the right thing, XLC 13 has a bug or maybe just sume specific
required symbols are not declared correctly?
Best regards
Christoph
> -Original Message-
> From: Ichiroh Takiguchi [mailto:[email protected]]
> Sent: Donnerstag, 31. Mai 2018 09:55
> To: L
openjdk.java.net
> Cc: 2d-dev <[email protected]>; Langer, Christoph
>
> Subject: RE: RFR: JDK-8204211: windows : handle potential C++ exception in
> GDIRenderer -was : RE: [OpenJDK 2D-Dev] java2d coding using
> SAFE_SIZE_ARRAY_ALLOC / safe_Malloc
>
> Hello, I prepared a
mail.
Best regards
Christoph
> -Original Message-
> From: Ichiroh Takiguchi [mailto:[email protected]]
> Sent: Dienstag, 5. Juni 2018 08:59
> To: Baesken, Matthias
> Cc: Langer, Christoph ; 'build-
> [email protected]' ; ppc-aix-port-
&
18 14:53
> To: [email protected]; [email protected]; core-
> [email protected]
> Cc: Lindenmaier, Goetz ; Baesken, Matthias
> ; Langer, Christoph
>
> Subject: RFR : 8204541 Correctly support AIX xlC 13.1 symbol visibility flags
>
> H
derstand what's happening there and fix it correctly
instead of just excluding osSupport.hpp.
Best regards
Christoph
> -Original Message-
> From: Ichiroh Takiguchi [mailto:[email protected]]
> Sent: Donnerstag, 7. Juni 2018 18:29
> To: Langer, Christoph
>
Hi Matthias,
looks good (and trivial). Ccing serviceability-dev because of change in libjdwp.
Best regards
Christoph
From: nio-dev On Behalf Of Baesken, Matthias
Sent: Mittwoch, 26. September 2018 11:25
To: '[email protected]' ; net-dev
; [email protected]
Cc: Lindenmaier, Goet
Hi Roman,
this looks good to me. +1
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Roman Kennke
> Sent: Mittwoch, 26. September 2018 19:24
> To: Magnus Ihse Bursie ; core-libs-
> [email protected]
> Cc: [email protected]
> Subject: Re: RFR: JDK
Hi Matthias,
looks good to me.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Donnerstag, 17. Januar 2019 07:41
> To: Steve Groeger
> Cc: '[email protected]' ; ppc-aix-
> [email protected]; ppc-aix-port-dev boun.
Hi,
may I please get reviews for the backport of this issue to jdk11u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8207849
Original Commit: http://hg.openjdk.java.net/jdk/jdk/rev/1edc62f9ba3a
Original review thread:
https://mail.openjdk.java.net/pipermail/build-dev/2018-July/022719.html
Webrev
Thanks, Magnus for the review.
I shall try wiggle 😊
> -Original Message-
> From: Magnus Ihse Bursie
> Sent: Freitag, 25. Januar 2019 11:21
> To: Langer, Christoph ; 'build-
> [email protected]'
> Cc: Zeller, Arno
> Subject: Re: RFR (S) [11u backpor
Hi,
I found that the variable JAVA_VERSION_INFO_RESOURCE gets defined in
make/launcher/LauncherCommon.gmk, while it is only used in
make/launcher/Launcher-java.base.gmk for the java and javaw launchers. I
thought it would make sense to move its definition into Launcher-java.base.gmk
to keep it
Hi Ralf,
thanks for proposing this fix. It looks good to me. Someone from the build
group should review it, too.
I can then push it.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Schmelter, Ralf
> Sent: Montag, 11. März 2019 13:22
> To: build-dev@openjd
Hi,
as per the mail discussion yesterday
(https://mail.openjdk.java.net/pipermail/build-dev/2019-March/025127.html),
please review the change to move the definition of JAVA_VERSION_INFO_RESOURCE
to Launcher-java.base.gmk.
Bug: https://bugs.openjdk.java.net/browse/JDK-8220504
Webrev: http://cr.
Thanks, Erik, for the review.
/Christoph
From: Erik Joelsson
Sent: Dienstag, 12. März 2019 15:53
To: Langer, Christoph ; [email protected]
Subject: Re: RFR(XS): 8220504: Move definition of JAVA_VERSION_INFO_RESOURCE to
Launcher-java.base.gmk
Looks good.
/Erik
On 2019-03-12 07:15
Hi,
the Mac experts will probably find my question to be silly and start laughing…
but nevertheless, I’m asking it here 😊
I was looking into building OpenJDK 8 today on my developer Mac, which runs
Mojave (10.14.3). configure immediately tells me, I need Xcode 4. So I was
trying to install xco
Hi Matthias,
first of all: The change looks good to me, +1.
I assume you have run it through our build/test infrastructure and see no
regressions...
As for the process:
In your case, you want to backport a change and the original patch does not
apply cleanly. For that scenario, you don't have t
Hi Andrew,
thanks for doing this backport. I agree, Severin's finding needs to be added to
hotspot's Unix/Posix vm.make files.
Also, the additional printing of those variables in the Unixish buildtree.make
files should be added to windows' make/windows/build.make in target
$(variantDir)\local.
Hi build-dev,
today I’m coming up with kind of a backward oriented suggestion… don’t know how
well that would be received. Let’s see.
For JDK 11, with JDK-8200132 [0], the JRE build has been moved to legacy.
There has been some discussion beforehand whether the JRE build can completely
be dropp
Hi,
> > Revised HotSpot webrev:
> >
> > https://cr.openjdk.java.net/~andrew/openjdk8/8189761/hotspot.02
>
> +++ new/src/share/vm/runtime/vm_version.cpp 2019-03-28
> 03:52:51.384737947 +
> @@ -140,7 +140,7 @@
>
> const char* Abstract_VM_Version::vm_vendor() {
> #ifdef VENDOR
> - return X
Looks good to me now 😊
> -Original Message-
> From: Andrew John Hughes
> Sent: Freitag, 29. März 2019 07:18
> To: Langer, Christoph ; Severin Gehwolf
> ; '[email protected]' [email protected]>; [email protected]
> Subject: Re: [
Hi Alan
> I'm curious who these "stakeholders" are and what they use these JRE
> bundle for? As you know, moving to a modular platform has blurred the
> historical distinction between what we knew as the JRE and JDK in the
> past. Are they concerned about disk space?
I think the requirement comes
. März 2019 15:54
To: Zeller, Arno ; Langer, Christoph
; [email protected]
Cc: Schuenemann, Rene
Subject: Re: RFR: 8221610: Resurrect (legacy) JRE bundle target
Hello,
On 2019-03-28 04:47, Zeller, Arno wrote:
Hi Christoph,
thanks for the patch. Just one small suggestion – I think you
Hi,
In our downstream build, I'd like to be able to set/customize the value for the
Windows RC properties "ProductName" and "FileDescription" via the
version-numbers file. These values manifest in Windows executable properties.
During the build ProductName gets set to "OpenJDK Platform 13" and
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Mittwoch, 3. April 2019 16:18
> To: Langer, Christoph ; build-
> [email protected]
> Subject: Re: RFR (S): 8221880: Better customization for Windows RC
> properties FileDescription and ProductName
>
> Hello Chri
Hi,
I'd like to backport the resurrection of the legacy JRE bundle target to jdk11
updates because it would help a lot in our build infrastructure. Maybe other
downstream vendors can take profit of this, too.
The patch doesn't apply cleanly, so I had to resolve a bit. Please review my
changes.
> > -Original Message-
> > From: Erik Joelsson
> > Sent: Mittwoch, 3. April 2019 16:18
> > To: Langer, Christoph ; build-
> > [email protected]
> > Subject: Re: RFR (S): 8221880: Better customization for Windows RC
> > properties FileDe
NAME from version-numbers at all and hard
> code the value "Platform" in make/autoconf/jdk-version.m4?
> >
> > /Christoph
> >
> >
> >> -Original Message-
> >> From: Langer, Christoph
> >> Sent: Mittwoch, 3. April 201
Hello Erik,
> >> In OpenJDK builds, the current strings evaluate to "OpenJDK Platform"
> >> and for Oracle builds "Java(TM) Platform SE". It makes me curious as to
> >> what you need to modify the string to?
> > We want to print "SapMachine" there, see this commit:
> >
> https://github.com/SAP/Sap
Hi Erik,
> > Good. Then we are back at my latest webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8221880.1/
>
> Ah, right, this change does not remove JDK_RC_PLATFORM_NAME from
> version-numbers, but it does remove it from spec.gmk.in. Could you leave
> it in spec.gmk.in? Then you can commi
Hi,
during work on JDK-8221880 I spotted some opportunity for cleanup in Windows
resource files and their handling in the build.
The naming of variables used for customizing resource properties in the build
system should be aligned between hotspot and JDK. This should be carefully
reviewed by
Thanks, Erik.
I already checked and will check carefully once again before pushing.
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 9. April 2019 15:22
> To: Langer, Christoph ; build-
> [email protected]; [email protected]
Hi Ralf,
looks good. I'll sponsor it for you.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Schmelter, Ralf
> Sent: Mittwoch, 10. April 2019 14:23
> To: [email protected]
> Subject: [CAUTION] RFR (S) Windows incremental build is broken with JDK-
>
Ok, about to do it now...
> -Original Message-
> From: Erik Joelsson
> Sent: Mittwoch, 10. April 2019 17:03
> To: Langer, Christoph ; Schmelter, Ralf
> ; [email protected]
> Subject: Re: RFR (S) Windows incremental build is broken with JDK-8217728
>
> Th
And done. 😊
> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 10. April 2019 17:13
> To: Erik Joelsson ; Schmelter, Ralf
> ; [email protected]
> Subject: RE: RFR (S) Windows incremental build is broken with JDK-8217728
>
>
Hi Man,
the change looks good to me, thanks for doing this cleanup.
As for reviewers: I thought it depends whether the author of a change is a
Reviewer himself. Then only one Reviewer needs to review the change. But I
might be wrong here. So, let's wait for a review from the build group and may
Hi,
please review a small build enhancement.
I'd like to add configure options for the Mac Bundle name/id:
--with-macosx-bundle-name-base and --with-macosx-bundle-id-base.
Bug: https://bugs.openjdk.java.net/browse/JDK-8222522
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222522.0/
Thank
Thanks Erik. I pushed it.
/Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 16. April 2019 15:22
> To: Langer, Christoph ; build-
> [email protected]
> Subject: Re: RFR(S): 8222522: Add configure options for Mac Bundle creation
>
>
Hi,
please review this little revert of a token that accidentally sneaked in when I
pushed JDK-8222522 (Add configure options for Mac Bundle creation) yesterday. I
don't know how that happened but fortunately it didn't break the build...
diff -r 15f2aae40bc8 -r ae1be0d04777 make/autoconf/jdk-ve
Thanks Volker. I see you are member of the build group… so I had a good feeling
when I pushed this 😊
http://hg.openjdk.java.net/jdk/jdk/rev/3b2101f56cdd
From: Volker Simonis
Sent: Mittwoch, 17. April 2019 07:54
To: Langer, Christoph
Cc: [email protected]
Subject: Re: RFR(XS
Hi Gary,
fair point.
cc-ing build-dev. Can you please check this change. Maybe you can comment on
the background why JDKLIB_LIBS does not include -ljava, too?
Thanks
Christoph
> -Original Message-
> From: Gary Adams
> Sent: Freitag, 26. April 2019 14:15
> To: Langer, Chr
Hi,
please help reviewing the backport of JDK-8210782: Upgrade HarfBuzz to the
latest 2.3.1.
This has been backported to 11.0.4-oracle already. I took the large change down
to 11u-dev. It applies quite nicely, apart from a little issue in
make/lib/Awt2dLibraries.gmk:
--- Awt2dLibraries.gmk
++
Ping: Can I please get a review for this?
From: Langer, Christoph
Sent: Dienstag, 30. April 2019 11:26
To: [email protected]
Cc: 2d-dev <[email protected]>; [email protected]; Baesken,
Matthias
Subject: [11u] RFR 8210782: Upgrade HarfBuzz to the latest 2.3
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 Max,
this looks all good to me now :)
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Weijun Wang
> Sent: Freitag, 31. Mai 2019 05:01
> To: Erik Joelsson
> Cc: [email protected]; build-dev [email protected]>
> Subject: Re: RFR 8193255: R
Hi Severin,
I think this is good.
Best regards
Christoph
> -Original Message-
> From: jdk8u-dev On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 25. Juni 2019 11:04
> To: jdk8u-dev
> Cc: build-dev
> Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
>
> Hi,
>
> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
> the 8u equivalent not also be applied to the solaris, bsd and aix
> subdirectories as well for consistency?
+1 We can test this for AIX.
Cheers
Christoph
> Here you go:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210761/jdk8/02/webrev/
>
> I cannot really test on bsd, solaris or aix, though :( Appreciate any
> testers for those platforms.
I pulled the patch into our test environment. It will be run for AIX and
solaris there. Will let y
ke the options don't work for Oracle Studio (12 u1) when compiling and
linking in one go. A fix would be to split compilation and linking of the lib
into 2 steps, I guess.
Best regards
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Donnerstag, 4. Juli
Hi Severin,
as we have the Solaris infrastructure in-house, let me try to produce something
for Solaris. I'll get back to you soon...
Cheers
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Donnerstag, 4. Juli 2019 14:18
> To: Langer, Christoph ; A
Hi Matthias,
looks good!
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Montag, 8. Juli 2019 14:00
> To: Thomas Stüfe
> Cc: [email protected]; [email protected]
> Subject: [CAUTION] 8227389: Remove unsuppo
++ compiler, but libjsig.o is compiled
with the C compiler. And the C compiler does not like -g0 but needs just -g.
Best regards
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Donnerstag, 4. Juli 2019 14:21
> To: Severin Gehwolf ; Andrew John Hughes
> ; jdk8u-d
Hi Severin,
You made a little mistake. It must be "-xO4" instead of "-x04" in the Solaris
build file (It's the letter O instead of the number 0) 😉
Best regards
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Dienstag, 9. Juli 2019 1
Hi Severin,
now it's good from my end. Finally 😊
Thanks
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Mittwoch, 10. Juli 2019 11:25
> To: Langer, Christoph
> Cc: build-dev ; Andrew John Hughes
> ; jdk8u-dev
> Subject: Re: [8u] RFR: 8210761:
Hi,
please review this little bugfix in Images.gmk.
Bug: https://bugs.openjdk.java.net/browse/JDK-8227578
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227578.0/
I guess it's only relevant when building "legacy-bundles" or something that
builds jre-images. However in that case we observe
Hi,
with today’s push for „8227578: Wrong JRE targets in Images.gmk after
JDK-8219971” I didn’t catch all issues with the JRE target and especially not
the one that’s causing our build errors. But now I’ve got it 😊
Please review this one line fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-
Hi Matthias,
I would second that.
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Dienstag, 16. Juli 2019 16:40
> To: '[email protected]'
> Subject: [CAUTION] build.log: Output from failing command(s) repeated
> here - do
Hi Matthias,
> May I have a second reviewer please?
Sure, looks good to me - this seems the right way to go forward 😊
Best regards
Christoph
Hi,
I've also played with this already and support Simon's patch.
Simon, shall I sponsor it for you?
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of Erik
> Joelsson
> Sent: Donnerstag, 12. September 2019 17:10
> To: David Holmes ; Simon Tooke
> ; build-dev
>
Done.
http://hg.openjdk.java.net/jdk/jdk/rev/593005ac5a0a
> -Original Message-
> From: Simon Tooke
> Sent: Donnerstag, 12. September 2019 22:25
> To: Langer, Christoph ; Erik Joelsson
> ; David Holmes ;
> build-dev
> Subject: Re: JDK 14 RFR: 821
David Holmes
> Sent: Mittwoch, 18. September 2019 01:13
> To: Erik Joelsson ; Magnus Ihse Bursie
> ; Langer, Christoph
> ; OpenJDK Serviceability [email protected]>; build-dev
> Subject: Re: RFR: 8230857: Avoid reflection in
> sun.tools.common.ProcessHelper
>
> Hi Eri
Hi,
please help reviewing this backport of a build infrastructure change to jdk11u.
One reason for doing this is parity with Oracle's 11.0.6 but the patch also
contains some test improvements which will help stabilizing 11u testing. This
mainly means increasing some test timeouts for a few test
Hi Severin,
good catch, thank you.
Adjusted webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212028.11u-dev.1/
Best regards
Christoph
> -Original Message-
> From: Severin Gehwolf
> Sent: Donnerstag, 10. Oktober 2019 15:15
> To: Langer, Christoph ; jdk-
Hi Severin,
backport looks good. Thanks for doing it.
Cheers
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 29. Oktober 2019 19:19
> To: jdk-updates-dev
> Cc: build-dev
> Subject: [11u] RFR: 8214311: dtrace gensrc has missing dependen
Sent: Mittwoch, 30. Oktober 2019 15:38
To: [email protected]; '[email protected]'
Cc: Langer, Christoph ; Doerr, Martin
Subject: RFR [XS] [jdk11] : 8233203: fix non-product build on AIX when
compiling with xlc16/legacy-xlc
Hello, please review the following
Hi,
I'm currently looking into native debug symbols support for Windows.
The OpenJDK build system supports these two configure flags
--with-native-debug-symbols= (among a few other options
which I don't want to discuss here).
So, the name implies that for "internal", debug symbols should be co
> -Original Message-
> From: Erik Joelsson
> Sent: Mittwoch, 4. Dezember 2019 15:46
> To: Bob Vandette
> Cc: Langer, Christoph ; build-
> [email protected]; [email protected]; hotspot-dev
> developers
> Subject: Re: native debug symbols support on
Hi René,
thanks for doing this.
I agree to Erik's findings, these should be addressed. Other than that, I have
no further points.
It would be good, if this little enhancement can be pushed before Thursday to
make it into JDK14 without special approval.
Best regards
Christoph
> -Original
Hi René,
LGTM, too.
I'll sponsor it for you.
Cheers
Christoph
> -Original Message-
> From: Erik Joelsson
> Sent: Dienstag, 10. Dezember 2019 15:35
> To: René Schünemann ; Langer, Christoph
>
> Cc: [email protected]
> Subject: Re: RFR: JDK-8235585
Hi Mikael (or build folks),
after 8234370 was submitted, I recognize the following output for configure:
stdin:85: warning: AC_REQUIRE: `PLATFORM_EXTRACT_TARGET_AND_BUILD' was expanded
before it was required
stdin:85:
http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Req
Hi Mikael,
thank you for fixing this.
Cheers
Christoph
From: Mikael Vidstedt
Sent: Mittwoch, 11. Dezember 2019 20:31
To: Langer, Christoph
Cc: build-dev
Subject: Re: RFR: 8234370: Implementation of JEP 362: Deprecate the Solaris and
SPARC Ports
Christoph,
Thanks for reporting! I filed
Hi,
please review the following change as a follow up to an earlier discussion
here: http://mail.openjdk.java.net/pipermail/build-dev/2019-December/026408.html
On Windows it's not possible to support configure option
"--with-native-debug-symbols=internal" in a way that one would expect. E.g.
n
Hi,
please review this simple backport of a simple build system fix which
unfortunately did not apply cleanly. It's just context changes that needed to
be resolved. I ran into this with jdk11u after I reinstalled my Visual Studio
to a non-default folder and used configure option --with-tools-di
Hi,
please review a backport of a carveout of JDK-8215445: "Enable building for
Windows in WSL" [0]. When building 11u after I've reinstalled Visual Studio and
the Windows Devkit to non-default folder locations, I ran into the issue that
ucrt.dll would not be correctly resolved, since it sits i
Thanks for the review, Martin.
> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 23. Dezember 2019 16:02
> To: Langer, Christoph ; jdk-updates-dev [email protected]>
> Cc: build-dev
> Subject: RE: [11u] RFR: 8236500: Windows ucrt.dll s
Thanks for the review, Martin.
> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 23. Dezember 2019 15:12
> To: Langer, Christoph ; jdk-updates-dev [email protected]>
> Cc: build-dev
> Subject: RE: [11u] RFR: 8232167: Visual Studio install
1 - 100 of 138 matches
Mail list logo
