Re: build failure in perfMemory_solaris.cpp?
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337: Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369: Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug 8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
Re: build failure in perfMemory_solaris.cpp?
Is there a bug id yet? I haven't seen one showing up in a quick search
for dd_fd or perfMemory_solaris.cpp.
For the record, I'm on what I think is the required platform/compilers:
% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
% more /etc/release
Oracle Solaris 11.1 SPARC
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
reserved.
Assembled 06 November 2013
% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
Brad
On 1/23/2015 8:32 AM, Volker Simonis wrote:
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337: Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369: Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug 8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
Re: build failure in perfMemory_solaris.cpp?
I created one:
https://bugs.openjdk.java.net/browse/JDK-8071501
Tony
On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
Is there a bug id yet? I haven't seen one showing up in a quick search
for dd_fd or perfMemory_solaris.cpp.
For the record, I'm on what I think is the required platform/compilers:
% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
% more /etc/release
Oracle Solaris 11.1 SPARC
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
reserved.
Assembled 06 November 2013
% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
Brad
On 1/23/2015 8:32 AM, Volker Simonis wrote:
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337: Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369: Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug
8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
Re: build failure in perfMemory_solaris.cpp?
by the timing when this started to happen, I believe
this was caused by the CPU changes integrated into jdk9/dev
on Wednesday (they didn't come through jdk9/hs).
I went to check those changesets and this looks like the prime suspect:
Changeset: c656c7540cb1
Author:gthornbr
Date: 2014-11-17 15:51 -0500
URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1
8050807: Better performing performance data handling
Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene
Contributed-by:gerald.thornbr...@oracle.com
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp
Jerry, I'm assigning the bug to you. Check it out and reassign if needed
Alejandro
On 1/23/2015 11:26 AM, Anthony Scarpino wrote:
I created one:
https://bugs.openjdk.java.net/browse/JDK-8071501
Tony
On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
Is there a bug id yet? I haven't seen one showing up in a quick search
for dd_fd or perfMemory_solaris.cpp.
For the record, I'm on what I think is the required platform/compilers:
% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
% more /etc/release
Oracle Solaris 11.1 SPARC
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
reserved.
Assembled 06 November 2013
% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
Brad
On 1/23/2015 8:32 AM, Volker Simonis wrote:
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on
SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337:
Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369:
Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug
8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
--
Alejandro
Re: RFR: JDK-8069261: Create make dependencies on make variable values
Hello, New webrev: On 2015-01-23 13:34, Magnus Ihse Bursie wrote: On 2015-01-23 12:17, Erik Joelsson wrote: * Added test-make to the all target so that it gets tested in JPRT. It takes close to no time to run. While I do like to see the make tests being run more frequently, I'm not sure I like the idea of adding them to the all target. I think building and testing should be kept as separate as possible, even if it matters testing the build system. If your goal is to get it run in JPRT, why not add it to the JPRT bundles target instead? Removed it for now. * For SetupArchive, I discovered that for vardeps changes, we have to force a full recreation of the jar to be sure those changes are really picked up. I also discovered that we currently didn't rebuild a jar if the manifest template file was changed. (I'm happy I had test-make tests for SetupArchive when fixing this.) Great! :-) Seems like it could be a good thing to add a test that changes to the manifest file trigger a build? :-) (The current test seems to bundle manifest updating with other changes which could by themselves trigger the update.) Implemented. /Erik
Re: RFR: JDK-8069261: Create make dependencies on make variable values
And the webrev link: http://cr.openjdk.java.net/~erikj/8069261/webrev.03/ /Erik On 2015-01-23 14:35, Erik Joelsson wrote: Hello, New webrev: On 2015-01-23 13:34, Magnus Ihse Bursie wrote: On 2015-01-23 12:17, Erik Joelsson wrote: * Added test-make to the all target so that it gets tested in JPRT. It takes close to no time to run. While I do like to see the make tests being run more frequently, I'm not sure I like the idea of adding them to the all target. I think building and testing should be kept as separate as possible, even if it matters testing the build system. If your goal is to get it run in JPRT, why not add it to the JPRT bundles target instead? Removed it for now. * For SetupArchive, I discovered that for vardeps changes, we have to force a full recreation of the jar to be sure those changes are really picked up. I also discovered that we currently didn't rebuild a jar if the manifest template file was changed. (I'm happy I had test-make tests for SetupArchive when fixing this.) Great! :-) Seems like it could be a good thing to add a test that changes to the manifest file trigger a build? :-) (The current test seems to bundle manifest updating with other changes which could by themselves trigger the update.) Implemented. /Erik
Re: build failure in perfMemory_solaris.cpp?
The Solaris problem doesn't appear when using our S10u6 devkits so
wasn't noticed internally. It isn't clear exactly when Solaris decided
to switch from SVR4 definition to POSIX definition. Not sure if we want
ugly ifdefs or wait until our official compiler set encounters the problem.
Can't comment on the AIX situation.
David
On 24/01/2015 8:07 AM, Alejandro E Murillo wrote:
by the timing when this started to happen, I believe
this was caused by the CPU changes integrated into jdk9/dev
on Wednesday (they didn't come through jdk9/hs).
I went to check those changesets and this looks like the prime suspect:
Changeset: c656c7540cb1
Author:gthornbr
Date: 2014-11-17 15:51 -0500
URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1
8050807: Better performing performance data handling
Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene
Contributed-by:gerald.thornbr...@oracle.com
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/share/vm/utilities/vmError.cpp
Jerry, I'm assigning the bug to you. Check it out and reassign if needed
Alejandro
On 1/23/2015 11:26 AM, Anthony Scarpino wrote:
I created one:
https://bugs.openjdk.java.net/browse/JDK-8071501
Tony
On 01/23/2015 10:07 AM, Bradford Wetmore wrote:
Is there a bug id yet? I haven't seen one showing up in a quick search
for dd_fd or perfMemory_solaris.cpp.
For the record, I'm on what I think is the required platform/compilers:
% uname -a
SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v
% more /etc/release
Oracle Solaris 11.1 SPARC
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
reserved.
Assembled 06 November 2013
% grep BUILD_CC out.txt
BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc
Brad
On 1/23/2015 8:32 AM, Volker Simonis wrote:
Hi,
we can see the same in our nightly OpenJDK 8/9 builds
(http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be
interested in a solution as well.
Thanks,
Volker
On Fri, Jan 23, 2015 at 5:19 AM, David Holmes
david.hol...@oracle.com wrote:
Hi Anthony,
On 23/01/2015 10:33 AM, Anthony Scarpino wrote:
Hi,
I just pulled the jdk9/dev gate today and hit a build failure on
SPARC
Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm
using SS12u3 compilers. Anyone else see a similar error or know what
might be going wrong?
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 337:
Error:
dd_fd is not a member of DIR.
...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp, line 369:
Error:
dd_fd is not a member of DIR.
gmake[8]: *** [perfMemory_solaris.o] Error 2
This code was brought in via the recent CPU integration of bug
8050807. (Hi
Jerry! - cc'd)
It looks like Solaris has two potential definitions of DIR:
#if defined(__USE_LEGACY_PROTOTYPES__)
/* traditional SVR4 definition */
typedef struct {
int dd_fd; /* file descriptor */
int dd_loc; /* offset in block */
int dd_size;/* amount of valid data */
char*dd_buf;/* directory block */
} DIR; /* stream data from opendir() */
#else
/* default definition (POSIX conformant) */
typedef struct {
int d_fd; /* file descriptor */
int d_loc; /* offset in block */
int d_size; /* amount of valid data */
char*d_buf; /* directory block */
} DIR; /* stream data from opendir() */
#endif /* __USE_LEGACY_PROTOTYPES__ */
I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably
either
something in Solaris 11.1, or something in SS12u3 is causing this
difference.
David
thanks
Tony
Re: Problem with Windows build - freetype.dll: %1 is not a valid Win32 application
On 2015-01-19 09:39, Mads Bondo Dydensborg wrote: Hi there As written about earlier, I have compiled OpenJDK on Windows 7 64 bit, using Visual Studio 2010 Express SP 1, under Cygwin. (eventually: make clean images). AFAIK, VS Express will only build a 32 bit image, and has done. A simple HelloWorld test seems to work. However, if I try to run anything graphical, I get a linker error regarding Freetype: mbd@LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/demo/jfc/FileChooserDemo $ ../../../bin/java.exe -jar FileChooserDemo.jar jan. 19, 2015 8:39:41 AM FileChooserDemo main SEVERE: null java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348) at FileChooserDemo.main(FileChooserDemo.java:796) Caused by: java.lang.UnsatisfiedLinkError: C:\apps\cygwin\home\mbd\Compile\openjdk-8-src-b132-03_mar_2014\openjdk\build\windows-x86-normal-server-release\images\j2sdk-image\jre\bin\freetype.dll: %1 is not a valid Win32 application at java.lang.ClassLoader$NativeLibrary.load(Native Method) (lots of FontManager = ClassLoader$NativeLibrary stuff). I am a bit new to Windows, but checking the lib in question: mbd@LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/jre/bin $ file freetype.dll freetype.dll: current ar archive mbd@LT01666 ~/Compile/openjdk-8-src-b132-03_mar_2014/openjdk/build/windows-x86-normal-server-release/images/j2sdk-image/jre/bin $ ldd freetype.dll ntdll.dll = /cygdrive/c/windows/SysWOW64/ntdll.dll (0x77e7) kernel32.dll = /cygdrive/c/windows/syswow64/kernel32.dll (0x7590) KERNELBASE.dll = /cygdrive/c/windows/syswow64/KERNELBASE.dll (0x75a1) I am not sure if it is 32 or 64 bit, really... As part of the build process, I had to create a copy of freetype.dll.a - this was installed in the X86 part of the Windows Program Files directory - I assumed that it was 32 bit. Any help/hints much appreciated. Freetype on Windows has long been a frustrating source of problems. In JDK9 there is a new configure option, --with-freetype-src, which helps out a lot with the problematic freetype on Windows. It just requires you to download the freetype source code and it will automatically compile a correct freetype library for use by OpenJDK. AFAIK this patch has not been backported to JDK8, however. But if you can switch to JDK9 I highly recommend it. An alternative solution might be to download JDK9 just to use this feature, and then point to the newly built freetype library using configure in JDK8. /Magnus
Re: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on windows
On 2015-01-22 15:40, Erik Joelsson wrote: Hello, The new LDFLAGS requires unpack200.exe to stop being linked differently to all other executables. There is no reason for this discrepancy that I can find, it just seems like someone did a bit of a quick hack getting it to build long ago in the old build, and we wanted to keep it equivalent in build-infra. I like the cleanup. Nevertheless, it would be good to check this by the group owning unpack200. Is it core libs? The hotspot build still requires the variables to be exported, so they are still being defined in hotspot-spec.gmk. While working on this, I stumbled on a problem when running make reconfigure. The PATH variable value, since exported in make, would get longer and longer for each time you run reconfigure. I fixed this by saving the original path and resetting it before running configure from make. Apart from wanting a second opinion on the unpack200 stuff, it looks good to me. Nice work! /Magnus
Re: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on windows
Adding Kumar since he has history in the unpack200 executable and I'm changing how it is being linked on Windows. In the old build, unpack200.exe was linked with cl.exe instead of link.exe like all other executables and libraries. Since the formatting of options is completely different, the same linker flags were not used. In this change, I'm removing this special treatment of unpack200.exe so that it is linked just like all other executables. /Erik On 2015-01-22 15:40, Erik Joelsson wrote: Hello, Please review this patch, which makes it possible to take a compile command line from the make debug log on Windows, and rerun it in a normal cygwin environment, without the need for running vsvars*.bat first. When building native code on windows, using Visual Studio, configure extracts the build environment from the setup .bat file provided by VS and sets 3 variables in spec.gmk: PATH, INCLUDE and LIB. These 3 variables are also exported into the environment in spec.gmk, so that every tool run by the build will see them. While this is convenient, it makes the command lines used by the build unusable outside of the build, unless you also export these variables with the correct values. I have removed the need for INCLUDE and LIB to be exported, by converting their contents into compiler and linker flags. These flags conceptually fit well in the recent SYSROOT_CFLAGS and SYSROOT_LDFLAGS variables. The PATH variable would be nice to not have to set, and while not setting it seems to work most of the time, I suspect that there are cases when it won't work. More specifically, in certain environments, some dll needed by the compiler program might not be on the path without it. So I left it being set for now. The new LDFLAGS requires unpack200.exe to stop being linked differently to all other executables. There is no reason for this discrepancy that I can find, it just seems like someone did a bit of a quick hack getting it to build long ago in the old build, and we wanted to keep it equivalent in build-infra. The hotspot build still requires the variables to be exported, so they are still being defined in hotspot-spec.gmk. While working on this, I stumbled on a problem when running make reconfigure. The PATH variable value, since exported in make, would get longer and longer for each time you run reconfigure. I fixed this by saving the original path and resetting it before running configure from make. Bug: https://bugs.openjdk.java.net/browse/JDK-8071329 Webrevs: http://cr.openjdk.java.net/~erikj/8071329/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8071329/webrev.jdk.01/ /Erik
Re: Building open jdk 8 from source fails
On 2015-01-18 04:47, lee json wrote: I switch to cloning repository at http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ by command `hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-dev` Then build with command line `bash ./configure --with-boot-jdk=/home/jason/jdk1.7.0_6` or `bash ./configure`. And then execute `make` or `make all` command. The first step i.e. configure successfully completes. Its output looks as the section configure. But failing compile source as the section of make, when calling make/ make all. With or wihtout make clean before make/ make all doesn't make any differences. How to fix such errors? Thanks It looks like you have not gotten all source code correctly. Just cloning the top-level repo is not enough. Try running bash get_source.sh. /Magnus
Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
David and Dmitry, thanks for the reviews!
dl
On 1/22/2015 11:41 PM, David Holmes wrote:
On 23/01/2015 5:36 PM, Dean Long wrote:
On 1/22/2015 11:01 PM, David Holmes wrote:
On 23/01/2015 4:01 AM, Dean Long wrote:
On 1/22/2015 2:19 AM, David Holmes wrote:
On 22/01/2015 8:39 AM, Dean Long wrote:
Thanks Dmitry. The updated webrev is here:
http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
This looks weird:
+ VMDEF_PAT = ^_ZTV
+ VMDEF_PAT := ^gHotSpotVM|$(VMDEF_PAT)
+ VMDEF_PAT := ^UseSharedSpaces$$|$(VMDEF_PAT)
+ VMDEF_PAT := ^_ZN9Arguments17SharedArchivePathE$$|$(VMDEF_PAT)
but I can sort of see why you wanted to do it that way.
Do you have a suggestion for a less-weird-looking way to do it?
Only the obvious but hard to read:
VMDEF_PAT :=
^_ZN9Arguments17SharedArchivePathE$$|^UseSharedSpaces$$|^gHotSpotVM|^_ZTV
Sure, I will do that. Can I count that as reviewed? And do I need
another Reviewer for this change, or am I good to go?
If you change it you will have to redo all your testing. Just leave
as-is - the readability wins here. Up to you though.
Dmitry and I have reviewed this. So you have one Reviewer and one
reviewer :)
Thanks,
David
dl
I assume you have verified the results are identical?
Yes.
I would be good to see this applied uniformly across all platforms as
well (except windows).
I suppose, but isn't linux the only platform where we might be
cross-compiling? I'm not setup to
build for aix, bsd, or solaris, and if I build in JPRT, I'm not
sure it
will save the vm.def or mapfile to
make a comparison against. Can we make cleaning up the other
platforms
a separate RFE?
Getting rid of shell scripts from the build is a Good Thing(TM)! But
yes we can make this a separate RFE.
Thanks,
David
dl
Thanks,
David
dl
On 1/21/2015 12:11 AM, Dmitry Samersoff wrote:
Dean,
vm.make ll. 247
1. *.o should be $(Obj_Files)
2.
$(NM) --defined-only *.o | sort -k3 -u |
awk '/$(VMDEF_PAT)/{ print \t $$3 ; }'
should give you the same result with less efforts
-Dmitry
On 2015-01-21 07:59, Dean Long wrote:
Here's version 2, which does everything in vm.make and doesn't do
anything that is shell-specific:
http://cr.openjdk.java.net/~dlong/8031064//webrev.2/
thanks,
dl
Re: RFR: JDK-8069261: Create make dependencies on make variable values
Hello, Thanks for the comments. Here is a new version: http://cr.openjdk.java.net/~erikj/8069261/webrev.02/ In addition to fixing the concerns below, I fixed the following: * Added test-make to the all target so that it gets tested in JPRT. It takes close to no time to run. * Added 1 second sleeps in the tests when running on macosx, since the filesystem on mac only has 1 second resolution. (WOW!) * Changed WriteFile to use printf instead of echo since echo on Solaris interprets things like '\t', which messes up comparisons. * Reworked how DependOnVariable is used in JavaCompilation.gmk. Instead of just blindly adding all input variables, I moved the definitions closer to the recipes, like in NativeCompilation.gmk. I think this is generally better, but the triggering reason was that too much unneeded stuff got into the vardep variable value and the command line got too long on Windows. * For SetupArchive, I discovered that for vardeps changes, we have to force a full recreation of the jar to be sure those changes are really picked up. I also discovered that we currently didn't rebuild a jar if the manifest template file was changed. (I'm happy I had test-make tests for SetupArchive when fixing this.) /Erik On 2015-01-21 15:42, Magnus Ihse Bursie wrote: Some minor comments. The name standard of the new vardeps files seems a bit vague. :) I suggest the following: * In JavaCompilation: $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, $$(dir $$($1_JAR))_the.$$($1_JARNAME)_vardeps) Use .vardeps instead * In MakeBase: DependOnVariableFileName = \ $(strip $(if $(strip $2), $2, \ $(MAKESUPPORT_OUTPUTDIR)/vardeps/$(DependOnVariableDirName)/$(strip $1).value)) Use .vardeps instead * Also, in Tools.gmk the additions: CFLAGS_windows := -nologo, \ seems to have crept in by mistake. * In NativeCompilation, the line: $$($1_RES): $$($1_VERSIONINFO_RESOURCE) $$($1_RES_VARDEPS_FILE) is mis-indented * Perhaps you can add some comment clarifying that $1_COMPILE_VARDEPS contains exactly the variables that add_native_source depend on, and that $1_COMPILE_VARDEPS_FILE is used by add_native_source? Otherwise, it looks all very good! /Magnus
Re: RFR: JDK-8055190: Cleanup include and exclude of core-libs native libraries after source code restructure
On 23/01/2015 14:35, Erik Joelsson wrote: Hello, Please review this build patch, cleaning up some in the native compilation of some core libraries. After the source code restructure into modules, the need for explicit exclude and include of source files was reduced. This patch moves some OS specific files to OS specific source dirs and adjusts the makefiles. It's based on Magnus' review comments on the source code restructure change. Bug: https://bugs.openjdk.java.net/browse/JDK-8055190 Webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.01/ /Erik This looks a good clean-up and demonstrates the usefulness of the new source layout. Can refs.allowed be removed? I thought we removed the JDK 8 dependency checker early in JDK 9 so this file shouldn't be needed. -Alan
Re: RFR: JDK-8069261: Create make dependencies on make variable values
On 2015-01-23 14:35, Erik Joelsson wrote: Hello, New webrev: On 2015-01-23 13:34, Magnus Ihse Bursie wrote: On 2015-01-23 12:17, Erik Joelsson wrote: * Added test-make to the all target so that it gets tested in JPRT. It takes close to no time to run. While I do like to see the make tests being run more frequently, I'm not sure I like the idea of adding them to the all target. I think building and testing should be kept as separate as possible, even if it matters testing the build system. If your goal is to get it run in JPRT, why not add it to the JPRT bundles target instead? Removed it for now. * For SetupArchive, I discovered that for vardeps changes, we have to force a full recreation of the jar to be sure those changes are really picked up. I also discovered that we currently didn't rebuild a jar if the manifest template file was changed. (I'm happy I had test-make tests for SetupArchive when fixing this.) Great! :-) Seems like it could be a good thing to add a test that changes to the manifest file trigger a build? :-) (The current test seems to bundle manifest updating with other changes which could by themselves trigger the update.) Implemented. Looks good to me. /Magnus
RFR: JDK-8055190: Cleanup include and exclude of core-libs native libraries after source code restructure
Hello, Please review this build patch, cleaning up some in the native compilation of some core libraries. After the source code restructure into modules, the need for explicit exclude and include of source files was reduced. This patch moves some OS specific files to OS specific source dirs and adjusts the makefiles. It's based on Magnus' review comments on the source code restructure change. Bug: https://bugs.openjdk.java.net/browse/JDK-8055190 Webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.01/ /Erik
Re: RFR: JDK-8055190: Cleanup include and exclude of core-libs native libraries after source code restructure
On 2015-01-23 15:41, Alan Bateman wrote: On 23/01/2015 14:35, Erik Joelsson wrote: Hello, Please review this build patch, cleaning up some in the native compilation of some core libraries. After the source code restructure into modules, the need for explicit exclude and include of source files was reduced. This patch moves some OS specific files to OS specific source dirs and adjusts the makefiles. It's based on Magnus' review comments on the source code restructure change. Bug: https://bugs.openjdk.java.net/browse/JDK-8055190 Webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.01/ /Erik This looks a good clean-up and demonstrates the usefulness of the new source layout. Thanks Can refs.allowed be removed? I thought we removed the JDK 8 dependency checker early in JDK 9 so this file shouldn't be needed. I was wondering what it was and could not find any usages. With your confirmation I have opted to remove it completely instead. Updated webrev: http://cr.openjdk.java.net/~erikj/8055190/webrev.02/ /Erik
Re: RFR: JDK-8069261: Create make dependencies on make variable values
On 2015-01-23 12:17, Erik Joelsson wrote: Hello, Thanks for the comments. Here is a new version: http://cr.openjdk.java.net/~erikj/8069261/webrev.02/ In addition to fixing the concerns below, I fixed the following: * Added test-make to the all target so that it gets tested in JPRT. It takes close to no time to run. While I do like to see the make tests being run more frequently, I'm not sure I like the idea of adding them to the all target. I think building and testing should be kept as separate as possible, even if it matters testing the build system. If your goal is to get it run in JPRT, why not add it to the JPRT bundles target instead? * Added 1 second sleeps in the tests when running on macosx, since the filesystem on mac only has 1 second resolution. (WOW!) * Changed WriteFile to use printf instead of echo since echo on Solaris interprets things like '\t', which messes up comparisons. * Reworked how DependOnVariable is used in JavaCompilation.gmk. Instead of just blindly adding all input variables, I moved the definitions closer to the recipes, like in NativeCompilation.gmk. I think this is generally better, but the triggering reason was that too much unneeded stuff got into the vardep variable value and the command line got too long on Windows. * For SetupArchive, I discovered that for vardeps changes, we have to force a full recreation of the jar to be sure those changes are really picked up. I also discovered that we currently didn't rebuild a jar if the manifest template file was changed. (I'm happy I had test-make tests for SetupArchive when fixing this.) Great! :-) Seems like it could be a good thing to add a test that changes to the manifest file trigger a build? :-) (The current test seems to bundle manifest updating with other changes which could by themselves trigger the update.) /Magnus /Erik On 2015-01-21 15:42, Magnus Ihse Bursie wrote: Some minor comments. The name standard of the new vardeps files seems a bit vague. :) I suggest the following: * In JavaCompilation: $1_VARDEPS_FILE := $$(call DependOnVariable, $1_VARDEPS, $$(dir $$($1_JAR))_the.$$($1_JARNAME)_vardeps) Use .vardeps instead * In MakeBase: DependOnVariableFileName = \ $(strip $(if $(strip $2), $2, \ $(MAKESUPPORT_OUTPUTDIR)/vardeps/$(DependOnVariableDirName)/$(strip $1).value)) Use .vardeps instead * Also, in Tools.gmk the additions: CFLAGS_windows := -nologo, \ seems to have crept in by mistake. * In NativeCompilation, the line: $$($1_RES): $$($1_VERSIONINFO_RESOURCE) $$($1_RES_VARDEPS_FILE) is mis-indented * Perhaps you can add some comment clarifying that $1_COMPILE_VARDEPS contains exactly the variables that add_native_source depend on, and that $1_COMPILE_VARDEPS_FILE is used by add_native_source? Otherwise, it looks all very good! /Magnus
