Re: RFR: JDK-8058631 Rename posix to unix in build system to match file name changes
On 2014-11-05 17:13, Volker Simonis wrote: Hi Magnus, I've looked at the change and I think it looks good. For any case I've also run an AIX build with your change applied and didn't encounter any problems. So thumbs up from me! Thanks! Regards, Volker PS: how did you produce a webrev from two repositories - do you have a special version of webrev? No special version, just the latest from the webrev repo. Use the -f switch to include sub-repos. For historical reasons it's named -f, for forest, but it is now converted to use the tree extension. (I did ran into an issue with the new tree extension support since I used nawk instead of gawk; a patch for that is under review.) And what's the best way to import such a change into mercurial (apart from 'patch'). I manually edited the patch file to make 'compatible' with 'qimport' but maybe there's a better way? I have no idea. :-) I think you'll need to use patch, since mercurial do not know about subrepos internally. Is there a problem with using patch? Maybe the trees extensions will need to implement a timport..? /Magnus
Re: RFR: AARCH64: Top-level JDK changes
On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ http://cr.openjdk.java.net/~aph/8064357-rev-1/ common/autoconf/flags.m4 +aarch64) + ZERO_ARCHFLAG= + ;; Why is this required on aarch64 but not all the other architectures? I think it's because GCC rejects -m64. Andrew.
Re: RFR: AARCH64: Top-level JDK changes
The changes look good besides the ones to common/autoconf/build-aux/config.sub When we did our initial check-in there have been objections to modify autoconf-config.guess because that one was copied directly from the autoconf project and should not be modified. I think the same applies to config.sub as well. But on the other side, we have an OpenJDK specific wrapper for autoconf-config.guess (i.e. config.guess) but there's no such wrapper for config.sub where we could fix-up things. So we have three possibilities: 1. make your change as suggested (which breaks the rule of not editing upstream files) 2. create a wrapper for config.sub, i.e. move config.sub to autoconf-config.sub and call it from config.sub which can contain arbitrary fix-up coding (which seems a little over-engineered IMHO) 3. pull in the new version of config.guess and config.sub from [1] which already seem to have the changes you need. I'm all in favour of point three which would also allow us to get rid of some of the hacks which are currently in config.guess. And now, as we're still early in the jdk9 development the risk of doing this seems minimal, but let's see what the build-dev guy say? Regards, Volker [1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD On Fri, Nov 7, 2014 at 6:34 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: CCing to build-dev and JDK9-dev since it is top level changes. Note, it will go into staging aarch64 repo. Vladimir On 11/7/14 9:21 AM, Andrew Haley wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ Andrew.
Re: RFR: AARCH64: Top-level JDK changes
On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ http://cr.openjdk.java.net/~aph/8064357-rev-1/ common/autoconf/flags.m4 +aarch64) + ZERO_ARCHFLAG= + ;; Why is this required on aarch64 but not all the other architectures? I think it's because GCC rejects -m64”. That’s interesting. I thought -marchbits is some kind of common flag that works on all architectures. Can someone verify this? Andrew.
Re: RFR: AARCH64: Top-level JDK changes
On 11/07/2014 06:10 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ http://cr.openjdk.java.net/~aph/8064357-rev-1/ common/autoconf/flags.m4 +aarch64) + ZERO_ARCHFLAG= + ;; Why is this required on aarch64 but not all the other architectures? I think it's because GCC rejects -m64”. That’s interesting. I thought -marchbits is some kind of common flag that works on all architectures. No, all the -m stuff is target-dependent. Can someone verify this? mustang-01:~ $ gcc -m64 hello.c gcc: error: unrecognized command line option '-m64' mustang-01:~ $ gcc --version gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Andrew.
Re: RFR: AARCH64: Top-level JDK changes
On Nov 7, 2014, at 10:10 AM, Christian Thalinger christian.thalin...@oracle.com wrote: On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ http://cr.openjdk.java.net/~aph/8064357-rev-1/ common/autoconf/flags.m4 +aarch64) + ZERO_ARCHFLAG= + ;; Why is this required on aarch64 but not all the other architectures? I think it's because GCC rejects -m64”. That’s interesting. I thought -marchbits is some kind of common flag that works on all architectures. Can someone verify this? This page doesn’t list it (while x86, SPARC, and PowerPC pages do): https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html I guess it’s good then. Andrew.
Re: RFR: AARCH64: Top-level JDK changes
On Nov 7, 2014, at 10:19 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 06:10 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:55 AM, Andrew Haley a...@redhat.com wrote: On 11/07/2014 05:42 PM, Christian Thalinger wrote: On Nov 7, 2014, at 9:21 AM, Andrew Haley a...@redhat.com wrote: The first patch: top-level build machinery changes. http://cr.openjdk.java.net/~aph/8064357-rev-1/ http://cr.openjdk.java.net/~aph/8064357-rev-1/ common/autoconf/flags.m4 +aarch64) + ZERO_ARCHFLAG= + ;; Why is this required on aarch64 but not all the other architectures? I think it's because GCC rejects -m64”. That’s interesting. I thought -marchbits is some kind of common flag that works on all architectures. No, all the -m stuff is target-dependent. Can someone verify this? mustang-01:~ $ gcc -m64 hello.c gcc: error: unrecognized command line option '-m64' mustang-01:~ $ gcc --version gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Thanks :-) Andrew.
Re: RFR: AARCH64: Top-level JDK changes
On 11/07/2014 06:00 PM, Volker Simonis wrote: 3. pull in the new version of config.guess and config.sub from [1] which already seem to have the changes you need. I'm all in favour of point three which would also allow us to get rid of some of the hacks which are currently in config.guess. And now, as we're still early in the jdk9 development the risk of doing this seems minimal, but let's see what the build-dev guy say? So am I. build-dev people, do you want me to import config.guess from upstream? I can create a new issue. Andrew.
adjust-mflags mangles paths into arguments
Steps to reproduce:
$ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u
$ cd jdk8u
$ sh get_source.sh
$ sh configure --with-freetype-include=/usr/include/freetype2
--with-freetype-lib=/usr/lib/x86_64-linux-gnu --with-debug-level=slowdebug
$ LOG=trace JOBS=1 make all
{}
+ echo
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug
/home/emr/jdk8u/hotspot/make/linux/makefiles/top.make:91: Building ad_stuff (from
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current)
(/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags newer)
++ pwd
+ echo
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug
/home/emr/jdk8u/hotspot/make/linux/makefiles/top.make:91: Building ad_stuff (from
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current)
(/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/platform.current
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags newer)
++
/home/emr/jdk8u/build/linux-x86_64-normal-server-slowdebug/hotspot/linux_amd64_compiler2/debug/../generated/adjust-mflags '-rRw -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common' 1
+ /usr/bin/make VERBOSE= LOG_LEVEL=trace -R -I /home/emr/jdk8u/make/common -f
adlc.make -r -rRw -I/home/emr/ -j1 -dk8u/make/common
-I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common
-I/home/emr/jdk8u/make/common -I/home/emr/jdk8u/make/common
/usr/bin/make: invalid option -- '8'
/usr/bin/make: invalid option -- 'u'
/usr/bin/make: invalid option -- '/'
/usr/bin/make: invalid option -- 'a'
/usr/bin/make: invalid option -- '/'
/usr/bin/make: invalid option -- 'c'
Usage: make [options] [target] ...
Options:
-b, -m Ignored for compatibility.
{}
As you can see, adjust-mflags is taking the path
/home/emr/jdk8u/make/common
and incorrectly converting it into
/home/emr/ -j1 -dk8u/make/common
Naturally, everything is boned from that point on. This occurs when
the all target gets to building hotspot.
