c 5, 2019, at 12:21 PM, Mandy Chung wrote:
>
>
>
> On 12/5/19 12:41 AM, Alan Bateman wrote:
>> On 05/12/2019 08:16, Henry Jen wrote:
>>> Hi,
>>>
>>> Updated webrev[1] reflect comments since last webrev. Vicente had done all
>>> the heavy-lift
Hi,
Updated webrev[1] reflect comments since last webrev. Vicente had done all the
heavy-lifting and hand over to me to finish up.
Changes to symbols is reverted, as we expect that only need to be updated in
next release by running make/scripts/generate-symbol-data.sh.
The jar files are confu
Thanks for the review, Alan and Magnus.
Cheers,
Henry
> On Nov 30, 2018, at 7:20 AM, Alan Bateman wrote:
>
>
>
> On 28/11/2018 22:49, Henry Jen wrote:
>> Since there is no header file in JDK provides the function prototypes, I
>> don’t think this is consid
Since there is no header file in JDK provides the function prototypes, I don’t
think this is considered public(supported) APIs.
Anyway, in case a tools is build with launcher code, and shipped separately
from JDK, that would be impacted by this bug. So I added a test call JLI_Launch
as well. Pl
> On Nov 28, 2018, at 12:46 AM, Alan Bateman wrote:
>
> On 27/11/2018 23:05, Henry Jen wrote:
>> Hi,
>>
>> Please review a follow up webrev[1] based on Priyanka’s patch, it simply
>> added a test case for Mac only that will link with libjli.
>> N
Hi,
Please review a follow up webrev[1] based on Priyanka’s patch, it simply added
a test case for Mac only that will link with libjli.
Note that, to use invoke API, one should probably link with libjvm, which works
for all supported platforms, not just Mac.
Cheers,
Henry
[1] http://cr.openjdk
Yes, it’s a known issue after upgrade Xcode,
https://bugs.openjdk.java.net/browse/JDK-8200550
Cheers,
Henry
> On Apr 12, 2018, at 11:19 AM, Magnus Ihse Bursie
> wrote:
>
> On 2018-04-12 19:42, Dan Smith wrote:
>> I'm suddenly getting hundreds of these warnings when I build in macOS:
>>
>> /
Hi,
Please review the webrev to remove jvisualvm from JDK9.
http://cr.openjdk.java.net/~henryjen/jdk9/8160881/jdk/webrev/
Cheers,
Henry
My upgrade experience is easier, all I need to do is run.
xcode-select —install.
Cheers,
Henry
> On Oct 1, 2015, at 2:20 PM, Dan Smith wrote:
>
> The OS X El Capitan installer cleans out the /usr directory, including
> /usr/X11R6. This is part of the System Integrity Protection feature [1]
Looks like hotspot team wants to verify new version of clang does the right
thing, I simply comment out the line to get a build.
As the test is for clang older than 6.1, I suspect it should be pretty safe to
do so. I’ll report back if my build have any problem, it seems fine so far.
Cheers,
Hen
> On Aug 12, 2015, at 7:55 AM, Kumar Srinivasan
> wrote:
>
> Henry,
>
> Generally looks good here are some comments, on my initial
> pass, I am not fully done with args.c I will look at this some
> more later today or tomorrow.
>
> 4.)
> expectingNoDash is expectingMain right ? if so I would
Hi,
Another update for argument file support, this version we added a couple
measures to ensure compatibility,
1) Compile time directive ENABLE_ARG_FILES is needed to enable the feature,
only java is enabled with this webrev.
2) Escape @argument if so desired: Additional prefixes of @ to a @ pr
Hi,
I am seeing following building errors on Traditional Chinese Windows 8, what
makes me wondering is why disable-warnings-as-errors not silence this? Did I
miss something obvious here?
Following is in my configure.log,
using configure arguments '--disable-warnings-as-errors --with-conf-name=r
Looks reasonable to me.
Cheers,
Henry
> On Jul 27, 2015, at 4:49 AM, Jan Lahoda wrote:
>
> Hi,
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8129562
>
> As part of the fix for JDK-8054717, CompileJavaModules.gmk is now using an
> "empty" bootclasspath (classes like java.lang.Object ar
Sigh, forgot the link to the webrev again.
http://cr.openjdk.java.net/~henryjen/jdk9/8027634/webrev/
Cheers,
Henry
> On Jul 9, 2015, at 8:48 PM, Henry Jen wrote:
>
> Hi,
>
> Please review proposed patch for JDK-8027634[1]. This patch is to enable java
> support command
Hi,
Please review proposed patch for JDK-8027634[1]. This patch is to enable java
support command line argument file like javac does. The implementation use the
same syntax rule, which is implemented in CommandLine.java[3] with
java.io.StreamTokenizer.
Some early comment is that we probably do
I have seen quite a few reports on this issue, and I don't know any good
reason not to.
A backport request JDK-8065267 is created, I will send out a request to
get proper approval.
Cheers,
Henry
On 11/18/2014 09:22 AM, Eric Caspole wrote:
Hi build-dev,
Is there any change this fix will make
On 06/10/2014 02:26 PM, David DeHaven wrote:
Can I get another Review on this?
Looks good to me.
$ sudo xcode-select -switch /Applications/old/Xcode4.app
$ make clean; sh ./configure; make images
Broken! The current Xcode command line tools don't run gcc as gcc even if Xcode
4 is active
N
+1. Not a "R"eviewer.
Cheers,
Henry
On 06/03/2014 11:07 AM, Joe Darcy wrote:
Hello,
I've started looking at clearing the javac "finally" lint category from
the JDK sources. Once that is done, please review the corresponding
makefile change to enable the warning the build:
diff -r cb15bc14c26a
On 05/28/2014 09:32 PM, Wang Weijun wrote:
On May 29, 2014, at 12:19, Henry Jen wrote:
On 05/28/2014 07:15 PM, Wang Weijun wrote:
On the other hand, it looks like xcodebuild is not always installed.
IIRC, this is what trigger the dialog ask what do you want to install. Can you
find
On 05/28/2014 07:15 PM, Wang Weijun wrote:
On the other hand, it looks like xcodebuild is not always installed.
IIRC, this is what trigger the dialog ask what do you want to install.
Can you find out where is your xcodebuild located and what does it
return with xcodebuild -version?
Cheer
eers,
Henry
/Erik
—Dan
On Apr 25, 2014, at 1:43 PM, Henry Jen wrote:
For JDK9, try to specify toolchain using --with-toolchain-type=gcc
Cheers,
Henry
On 04/25/2014 10:41 AM, Dan Smith wrote:
I'm using --with-tools-dir on OS X Mavericks to point to an old copy
of Xcode 4. I configure
For JDK9, try to specify toolchain using --with-toolchain-type=gcc
Cheers,
Henry
On 04/25/2014 10:41 AM, Dan Smith wrote:
I'm using --with-tools-dir on OS X Mavericks to point to an old copy of Xcode
4. I configure jdk9 as follows:
make dist-clean
hg update -d "<2014-03-17"
sh configure --w
Workaround is to revert the bsd makefile change, this will get you a
build on Mac as before,
--- a/make/bsd/makefiles/gcc.make Tue Mar 04 09:57:16 2014 -0500
+++ b/make/bsd/makefiles/gcc.make Mon Mar 03 11:54:35 2014 +0100
@@ -260,7 +260,7 @@
WARNINGS_ARE_ERRORS += -Wno-empty-bod
Looks good.
Cheers,
Henry
On 03/10/2014 03:59 AM, Erik Joelsson wrote:
Hello,
Please review this simple fix which was also triggered by the properties
files cleanup. On (at least) some Solaris configurations, sort fails if
certain LC_xxx variables are set. The solution is to set LC_ALL=C
inst
in this code
at the moment. I think it looks good ok, but would prefer if he got the chance
to look at it too.
/Erik
On 2014-03-06 01:11, Henry Jen wrote:
Ping! Is three any concern on this patch? I got JPRT reports no problem and
other reports success.
I hope we can get this in as early as
Ping! Is three any concern on this patch? I got JPRT reports no problem
and other reports success.
I hope we can get this in as early as we can because build is evloving
quickly, and I think it only can get better after pushed for more tests.
Cheers,
Henry
On 02/26/2014 12:23 AM, Henry Jen
On 02/26/2014 06:54 PM, David Holmes wrote:
On 27/02/2014 4:17 AM, Henry Jen wrote:
Thanks, Staffan.
Need another review before push to hotspot. Would it be OK for hotspot
team if we push this through jdk9/dev?
Looks okay to me. Can't approve/not-approve the push to jdk9/dev though
- b
,
Henry
On 02/26/2014 12:24 AM, Staffan Larsen wrote:
Looks good!
Thanks,
/Staffan
On 26 feb 2014, at 09:08, Henry Jen wrote:
Hi,
Please review a simple webrev that ensure we link with libstdc++ when using
clang instead of libc++, libc++ is default for Xcode5.
Per clang man page
Hi,
Please review a webrev to enable XCode5 build on Mac OS X, this webrev
add basic clang flags and detect Xcode version to set default toolchain
to clang for Xcode5 and after, otherwise set to gcc for Mac OS X.
http://cr.openjdk.java.net/~henryjen/jdk9/8019470/1/webrev/
This patch build on
Hi,
Please review a simple webrev that ensure we link with libstdc++ when
using clang instead of libc++, libc++ is default for Xcode5.
Per clang man page,
-stdlib=library
Specify the C++ standard library to use; supported options are
libstdc++ and libc++.
Bug:
I say ship it given you have tested it, and I don't see anything raise a flag.
But I am not a JDK reviewer.
Cheers,
Henry
- Original Message -
From: magnus.ihse.bur...@oracle.com
To: erik.joels...@oracle.com
Cc: build-dev@openjdk.java.net
Sent: Thursday, February 20, 2014 6:46:44 AM GMT
On 02/13/2014 12:41 AM, Magnus Ihse Bursie wrote:
Henry,
- Do we want to allow convention name cc and CC and detect what it
is or simply ask for explicit choice as it is imeplemted now?
Although I don't think it's likely for a system to install, say
gcc, as cc instead of create a symbolic link
Good progress, it build for me on Arch Linux with gcc, not working for
clang yet(perhaps expected). A few comments from what I read so far,
- --with-toolchain-type=list shows up after quite a few configure going
on already, we probably want to have this done in an earlier stage.
- The "availa
On 02/12/2014 07:11 AM, Magnus Ihse Bursie wrote:
12 feb 2014 kl. 14:55 skrev Erik Joelsson :
First I was disappointed to lose the configure-arguments file, which I
sometimes look in to see how configure was run, but I can just as well look in
spec.gmk.
Yes, that was my own reaction too. :-
On 01/31/2014 08:09 AM, Martin Buchholz wrote:
I think it's generally wrong to use a "compiler type" just like it's
generally wrong to use a "OS type". Most code should be portable, and most
of the rest should use autoconf features "HAVE_FOO"
Getting openjdk to build with random compilers (e.g.
I haven't tried this, but Tim Bell mentioned this in an email inquiry I
had earlier,
This will be cured when the fix for 8021266 is pushed to JDK 9 (see
attached).
In the meantime, the workaround in JPRT is to submit your JDK 9 jobs
with '-bootproduct jdk7u7' since the 7u51 release can not ser
as you use Jprt and push
to the correct group repo.
Cool, I will do that and push to jdk9/dev/hotspot.
Cheers,
Henry
/Erik
On 2014-01-17 21:03, Henry Jen wrote:
Hi,
This is a follow up on an issue first reported on Nov. 2, the fix had
been discussed at that time[1] and works for me.
The
Hi,
This is a follow up on an issue first reported on Nov. 2, the fix had
been discussed at that time[1] and works for me.
The issue is that the sed command in adjust-mflags.sh trying to isolate
-j switch failed to deal with new MFLAGS format spitted out by gmake 4,
where the -I without a sp
t; s/^-/ -/
>> - s/ -\([^ ][^ ]*\)j/ -\1 -j/
>> + s/ -\([^ I][^ ]*\)j/ -\1 -j/
>> s/ -j[0-9][0-9]*/ -j/
>> s/ -j\([^ ]\)/ -j -\1/
>> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/
>>
>> /Erik
>>
>>
s/ -j[0-9][0-9]*/ -j/
> s/ -j\([^ ]\)/ -j -\1/
> s/ -j/ -j'${HOTSPOT_BUILD_JOBS:-${default_build_jobs}}'/
>
> /Erik
>
> On 2013-11-05 07:18, Henry Jen wrote:
>> Yes, GNU make 4.0 change the format of MFLAGS so that there is no longer
&
completely different
reason so I didn't pursue the problem).
We will investigate.
/Erik
On 2013-11-02 08:30, Henry Jen wrote:
What I don't understand(misleading me) is that my previous Ubuntu
setup has same directory structure, but not seeing this problem.
Cheers,
Henry
On 11/02/2013 12:27
What I don't understand(misleading me) is that my previous Ubuntu setup
has same directory structure, but not seeing this problem.
Cheers,
Henry
On 11/02/2013 12:27 AM, Henry Jen wrote:
Yes, I just verified that's the result of sed. Following patch fix it.
I don't quite underst
s/tl/common/makefiles
Note the -j3 which seems to have been inserted into the middle of
/hjen/ws ...
David
On 2/11/2013 1:36 PM, Henry Jen wrote:
Hi,
I am trying to setup build environment on a new installation, and
encounter following build error.
I suspect this is because of missing some r
Hi,
I am trying to setup build environment on a new installation, and
encounter following build error.
I suspect this is because of missing some required tools and software,
however, the error message is not helpful.
Tried to echo the make commang used, but as you can see the output seems
On 08/08/2013 04:49 AM, Dmitry Samersoff wrote:
> Filed a bug:
>
> https://jbs.oracle.com/bugs/browse/JDK-8022617
>
Thanks, my search didn't show that one but the one for Mac OS which is
resolved.
Cheers,
Henry
On 08/09/2013 12:32 PM, Mike Duigou wrote:
>
> On Aug 8 2013, at 22:57 , David Holmes wrote:
>
>> On 9/08/2013 3:31 PM, Henry Jen wrote:
>>> man gcc on mac,
>>>
>>>>file.s
>>>>Assembler code. Apple's version of G
man gcc on mac,
>file.s
>Assembler code. Apple's version of GCC runs the preprocessor on
> these files as well as those ending in .S.
>
>file.S
>Assembler code which must be preprocessed.
>
Cheers,
Henry
On Aug 8, 2013, at 5:36 AM, David Holmes wrote
48 matches
Mail list logo