Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
Dean,
Looks good for me. (not a reviewer)
Thank you for fixing it.
-Dmitry
On 2015-01-22 01:39, Dean Long wrote:
Thanks Dmitry. The updated webrev is here:
http://cr.openjdk.java.net/~dlong/8031064/webrev.3/
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
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
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.
I assume you have verified the results are identical?
I would be good to see this applied uniformly across all platforms as
well (except windows).
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
RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on windows
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: build failure in perfMemory_solaris.cpp?
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
build failure in perfMemory_solaris.cpp?
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 thanks Tony
Re: RFR: JDK-8071329: Stop exporting INCLUDE and LIB when building on windows
Hiya Erik , FWIW, this looks not unreasonable to this non-reviewer. By way of an aside, I have nearly completed a set of changes to the make files (in our repos) that, IMO, considerably improves the readability of makefiles in which there are calls to macros using extended argument lists - by judicious use of alignment of the ':=' together with continuation lines. Presumably, I'd have to raise a bug to cover such changes ? TIA best rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 22 January 2015 at 14:40, Erik Joelsson erik.joels...@oracle.com 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: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
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?
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?
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 (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
Dean,
Can we make cleaning up the other platforms
a separate RFE?
I think yes. So please file the RFE.
-Dmitry
On 2015-01-22 21:01, 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?
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?
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
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
Re: RFR (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
Done: https://bugs.openjdk.java.net/browse/JDK-8071436
dl
On 1/22/2015 10:45 PM, Dmitry Samersoff wrote:
Dean,
Can we make cleaning up the other platforms
a separate RFE?
I think yes. So please file the RFE.
-Dmitry
On 2015-01-22 21:01, 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?
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?
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 (XS) 8031064: build_vm_def.sh not working correctly for new build cross compile
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
