From david.holmes at oracle.com Thu May 1 05:45:49 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 May 2014 15:45:49 +1000 Subject: Proposal: jtreg tests with native components In-Reply-To: <6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com> References: <5360C4EB.80201@oracle.com> <6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com> Message-ID: <5361DF8D.5010800@oracle.com> On 30/04/2014 9:39 PM, Staffan Larsen wrote: > > On 30 apr 2014, at 11:39, David Holmes wrote: > >> Hi Staffan, >> >> On 25/04/2014 10:02 PM, Staffan Larsen wrote: >>> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways: >>> >>> 1) The binaries are pre-compiled and checked into the repository (often inside jar files). >>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run. >>> >>> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained. >> >> #2 is far from perfect but ... >> >>> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms. >>> >>> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located. >> >> don't under estimate the complexity involved in building then "distributing" the test binaries. > > I don?t. It will be complicated, but I?m sure we can do it. The question is whether it is worth it relative to the size of the problem. >> >> You will still need to maintain platform specific logic as you won't necessarily be able to use the CFLAGS etc that the main build process uses. > > Can you explain more? Why can?t I use CFLAGS as it is? You _may_ be able to, you may not. I know we already had issues where the CFLAGS as being used for the JDK sources also got applied to building the code-generator utility programs and that didn't work correctly. Here's sample CFLAGS from a JDK build CFLAGS_JDKLIB:= -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 -DRELEASE='"$(RELEASE)"' -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include/linux -I/export/users/dh198349/jdk8u-dev/jdk/src/share/javavm/export -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/javavm/export -I/export/users/dh198349/jdk8u-dev/jdk/src/share/native/common -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/native/common -m32 -fno-strict-aliasing -fPIC Does that make sense for compiling a test? Does it depend on whether we are building a native library or a native executable? >> >> Also talk to SQE as I'm pretty sure there is an existing project to look at how to better handle this, at least for the internal test suites. > > I have talked to SQE. I don?t know of any other projects to handle this. :) It wasn't SQE, it was your project as referenced in a few bug reports last August/September. David > /Staffan > > >> >> David >> ----- >> >>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started. >>> >>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components. >>> >>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository. >>> >>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such. >>> >>> Thanks, >>> /Staffan >>> > From chris.hegarty at oracle.com Thu May 1 09:52:41 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 May 2014 10:52:41 +0100 Subject: RFR [9] : get_source.sh should be more friendly to MQ In-Reply-To: <21342.44904.883366.760719@mykonos.us.oracle.com> References: <53480316.2090806@oracle.com> <53480349.6000702@oracle.com> <534805A4.4030607@oracle.com> <21342.44904.883366.760719@mykonos.us.oracle.com> Message-ID: <43BCC373-B571-4488-A0E9-743E1C6583CC@oracle.com> John, Mike, Thanks for your comments. I?ve been using rebase for a while now and it certainly makes resolving conflicts in patches much easier, as opposed to manually inspecting reject files. My workflow is as per your suggestion, bash common/bin/hgforest.sh push -a bash common/bin/hgforest.sh pull ?rebase Give that not everyone wants to operate this way, using rebase, I?m not sure what, if anything, can be added to get_source.sh to support this. Maybe I just need to omit get_source.sh from my workflow after the initial clone? -Chris. On 28 Apr 2014, at 20:43, John Coomes wrote: > Chris Hegarty (chris.hegarty at oracle.com) wrote: >> On 11/04/14 15:59, Jonathan Gibbons wrote: >>> Popping all patches beforehand is reasonable, but afterwards, it would >>> be better to reset to the patches that were previously applied than to >>> try and push all of them. >> >> Michael as requested same. >> >>> What is the behavior if you cannot qpush patches after the pull, because >>> of merge issues? >> >> The parts of the specific patch that applied cleanly remain applied, >> them that did not are written out to reject files to be analyzed. The >> remainder of the patches in that repository are not applied. get_source >> will then exit with an appropriate error exit code and you can take action. > > [Sorry for resurrecting this thread, I just became aware of it--was not > subscribed.] > > My workflow relies heavily on mq and (IMHO, of course) reject files > are needless tedium. So I depend heavily on rebase. In order to > avoid reject files when pulling, I do: > > hg qpush -a # push everything > > hg pull --rebase # pull and rebase in one step, will > # invoke merge tools if necessary > > hg qpop # optional > > If you omit the 'hg qpush -a' before pulling, it becomes tedious > (sometimes impossible) to get your merge tools invoked when you later > want to push the patches. > > -John > >>> On 04/11/2014 07:58 AM, Chris Hegarty wrote: >>>> Anyone using MQ for their daily development will know about this, >>>> forgetting to qpop before sync'ing up. It would be nice it get_source >>>> would pop and push patches ( only if you are using MQ ) automatically. >>>> If you do not have patch repos, then there is no change. >>>> >>>> diff --git a/get_source.sh b/get_source.sh >>>> --- a/get_source.sh >>>> +++ b/get_source.sh >>>> @@ -28,6 +28,21 @@ >>>> # Get clones of all nested repositories >>>> sh ./common/bin/hgforest.sh clone "$@" || exit 1 >>>> >>>> +patchdirs=`ls -d ./.hg/patches ./*/.hg/patches ./*/*/.hg/patches \ >>>> + ./*/*/*/.hg/patches ./*/*/*/*/.hg/patches 2>/dev/null` >>>> + >>>> +# Pop all patches, if any, before updating >>>> +if [ "${patchdirs}" != "" ] ; then >>>> + echo "Found queue repository, qpop." >>>> + sh ./common/bin/hgforest.sh qpop -a || exit 1 >>>> +fi >>>> + >>>> # Update all existing repositories to the latest sources >>>> -sh ./common/bin/hgforest.sh pull -u >>>> +sh ./common/bin/hgforest.sh pull -u || exit 1 >>>> >>>> +# Push all patches, if any, after updating >>>> +if [ "${patchdirs}" != "" ] ; then >>>> + echo "Found queue repository, qpush." >>>> + sh ./common/bin/hgforest.sh qpush -a >>>> +fi >>>> + >>>> >>>> -Chris. >>> > > -- > John Coomes Oracle, MS USCA22-3?? > john.coomes at oracle.com 4220 Network Circle > 408-276-7048 Santa Clara, CA 95054-1778 > *** Support GreenPeace and we'll all breathe easier. *** From dmitry.samersoff at oracle.com Thu May 1 16:12:30 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 01 May 2014 20:12:30 +0400 Subject: Proposal: jtreg tests with native components In-Reply-To: References: Message-ID: <5362726E.9030102@oracle.com> Staffan, Couple of tests require both Java and native code, so compiling it's all into the single directory might be a problem. Some test used to access additional data in TESTSRC so we have to copy it as well. One of possible solution is to allow the tests to support two independent steps - "build" and "run". on build side - run all tests with "build" parameter, tests that don't have build step will just do nothing and continue work as today. Then bundle entire test tree. on test side - run all tests with the "run" parameters. Test that have build step have to copy all required files from build output directory to work directory. JDK configuration options could be provided through include file for make/shell or property file. It allows the test to achieve whatever build and test behavior it requires and allows us to move to right direction, without breaking existing things. -Dmitry On 2014-04-25 16:02, Staffan Larsen wrote: > There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways: > > 1) The binaries are pre-compiled and checked into the repository (often inside jar files). > 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run. > > Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained. > > I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms. > > If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located. > > I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started. > > To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components. > > This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository. > > Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such. > > Thanks, > /Staffan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From erik.helin at oracle.com Thu May 1 16:14:58 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 01 May 2014 18:14:58 +0200 Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used In-Reply-To: <5360E0D5.90203@oracle.com> References: <52F8EB7A.4080305@oracle.com> <5360DDC8.2000003@oracle.com> <5360E0D5.90203@oracle.com> Message-ID: <3005492.Fkng45DX1Y@ehelin-laptop> Hi Erik, thanks for having a look at the patches! On Wednesday 30 April 2014 13:39:01 PM Erik Joelsson wrote: > I think option 2 seems best. Ok, that is my preferred option as well, thanks! Erik > /Erik > > On 2014-04-30 13:26, Erik Helin wrote: > > Anyone interested in this patch? I ran into this issue again yesterday... > > > > Thanks, > > Erik > > > > On 2014-02-10 16:21, Erik Helin wrote: > >> Sigh, I forgot the subject... > >> > >> "RFR: 8034094: SA agent can't compile when jni_x86.h is used" > >> > >> Thanks, > >> Erik > >> > >> On 2014-02-10 16:08, Erik Helin wrote: > >>> Hi all, > >>> > >>> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and > >>> jni_md.h. > >>> > >>> The bug manifests itself when using an IMPORT_JDK which > >>> include/linux/jni_md.h has a timestamp that is older than > >>> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will > >>> copy hotspot/src/cpu/x86/jni_x86.h to > >>> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. > >>> > >>> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from > >>> jdk/include/jni.h, since it is used for all operating systems: > >>> > >>> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) > >>> ... // common stuff > >>> #else > >>> ... // windows stuff > >>> #endif > >>> > >>> We compile the SA agent, see make/linux/makefiles/saproc.make, without > >>> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). > >>> > >>> In my opinion, there are two ways to solve this: > >>> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding > >>> > >>> defines for Solaris and BSD). > >>> > >>> 2. Rewrite the #if check in jni_x86.h to use platform specific "native" > >>> > >>> defines. > >>> > >>> I've created a patch for each alternative: > >>> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ > >>> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ > >>> > >>> For the second patch, note that I've inverted the #if check so that it > >>> checks for _WIN32 is defined and treat all others operating systems as > >>> "#else". > >>> > >>> Bug: > >>> https://bugs.openjdk.java.net/browse/JDK-8034094 > >>> > >>> Testing: > >>> - Compiled both version locally and made sure it worked > >>> - JPRT > >>> > >>> Thanks, > >>> Erik From erik.helin at oracle.com Thu May 1 16:16:31 2014 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 01 May 2014 18:16:31 +0200 Subject: RFR: 8034094: SA agent can't compile when jni_x86.h is used In-Reply-To: <53614C90.2080701@oracle.com> References: <52F8EB7A.4080305@oracle.com> <52F8EE89.6040808@oracle.com> <53614C90.2080701@oracle.com> Message-ID: <1542127.onZt1XuZ2J@ehelin-laptop> On Wednesday 30 April 2014 23:18:40 PM Dmitry Samersoff wrote: > Erik, > > Sorry, missed the thread. No problem, thanks for having a look! On Wednesday 30 April 2014 23:18:40 PM Dmitry Samersoff wrote: > Changes (option 2) looks good for me. Thanks! Erik On Wednesday 30 April 2014 23:18:40 PM Dmitry Samersoff wrote: > -Dmitry > > On 2014-02-10 19:21, Erik Helin wrote: > > Sigh, I forgot the subject... > > > > "RFR: 8034094: SA agent can't compile when jni_x86.h is used" > > > > Thanks, > > Erik > > > > On 2014-02-10 16:08, Erik Helin wrote: > >> Hi all, > >> > >> this patch fixes an issue with HotSpot's makefiles, IMPORT_JDK and > >> jni_md.h. > >> > >> The bug manifests itself when using an IMPORT_JDK which > >> include/linux/jni_md.h has a timestamp that is older than > >> hotspot/src/cpu/x86/jni_x86.h. When this happens, the Makefiles will > >> copy hotspot/src/cpu/x86/jni_x86.h to > >> hotspot/build/jdk-linux-amd64/fastdebug/include/linux/jni_md.h. > >> > >> The issue is that hotspot/src/cpu/x86/jni_x86.h differs slightly from > >> jdk/include/jni.h, since it is used for all operating systems: > >> > >> #if defined(SOLARIS) || defined(LINUX) || defined(_ALLBSD_SOURCE) > >> ... // common stuff > >> #else > >> ... // windows stuff > >> #endif > >> > >> We compile the SA agent, see make/linux/makefiles/saproc.make, without > >> defining LINUX (LINUX is hotspot's own define, gcc uses __linux__). > >> > >> In my opinion, there are two ways to solve this: > >> 1. Add -DLINUX to make/linux/makefiles/saproc.make (and corresponding > >> > >> defines for Solaris and BSD). > >> > >> 2. Rewrite the #if check in jni_x86.h to use platform specific "native" > >> > >> defines. > >> > >> I've created a patch for each alternative: > >> 1: http://cr.openjdk.java.net/~ehelin/8034094/webrev.1/ > >> 2: http://cr.openjdk.java.net/~ehelin/8034094/webrev.2/ > >> > >> For the second patch, note that I've inverted the #if check so that it > >> checks for _WIN32 is defined and treat all others operating systems as > >> "#else". > >> > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8034094 > >> > >> Testing: > >> - Compiled both version locally and made sure it worked > >> - JPRT > >> > >> Thanks, > >> Erik From jonathan.gibbons at oracle.com Thu May 1 16:24:14 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 01 May 2014 09:24:14 -0700 Subject: Proposal: jtreg tests with native components In-Reply-To: <5362726E.9030102@oracle.com> References: <5362726E.9030102@oracle.com> Message-ID: <5362752E.204@oracle.com> Dmitry, Beyond Staffan's proposal for jtreg to provide tests with a pointer to the location of precompiled native code, there are no plans to change the way jtreg execute tests, processes action tags like @build, @run, etc. -- Jon On 05/01/2014 09:12 AM, Dmitry Samersoff wrote: > Staffan, > > Couple of tests require both Java and native code, so compiling it's all > into the single directory might be a problem. Some test used to access > additional data in TESTSRC so we have to copy it as well. > > One of possible solution is to allow the tests to support two > independent steps - "build" and "run". > > on build side - run all tests with "build" parameter, tests that don't > have build step will just do nothing and continue work as today. Then > bundle entire test tree. > > on test side - run all tests with the "run" parameters. Test that have > build step have to copy all required files from build output directory > to work directory. > > JDK configuration options could be provided through include file for > make/shell or property file. > > It allows the test to achieve whatever build and test behavior it > requires and allows us to move to right direction, without breaking > existing things. > > -Dmitry > > On 2014-04-25 16:02, Staffan Larsen wrote: >> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways: >> >> 1) The binaries are pre-compiled and checked into the repository (often inside jar files). >> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run. >> >> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained. >> >> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms. >> >> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located. >> >> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started. >> >> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components. >> >> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository. >> >> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such. >> >> Thanks, >> /Staffan >> > From james.connors at oracle.com Fri May 2 04:00:41 2014 From: james.connors at oracle.com (Jim Connors) Date: Fri, 02 May 2014 00:00:41 -0400 Subject: Build OpenJDK 8 for armhf (Raspberry Pi)? In-Reply-To: <535FD499.3020905@oracle.com> References: <535FD499.3020905@oracle.com> Message-ID: <53631869.3020507@oracle.com> Hello again, Just thought I'd provide an update to the forum about my travails in trying to build an armhf version of OpenJDK 8... Gave up trying to cross-compile, and instead built it natively on an Arm device. The Rasberry Pi is woefully underpowered for such and endeavor, but I do have a quad-core Cortex-A9 device which is a lot faster. No way near the speed of even a modest laptop, but nonetheless much better. After fits and starts, here's the configuration which enabled a partial build: $ bash configure --with-jvm-variants=zero --disable-headful --with-memory-size=1024 --enable-openjdk-only Comments: 1. Added "--disable-headful" because there were errors building what looked like part of Java 2d. As no graphics were required, a headless build is just fine. 2. Added "--with-memory-size=1024". This device only has 1GB RAM, and without this option, configure will specify that BOOT_JAVAC be run with the following options: "-Xms256M -Xmx512M". When it comes time to compiling the 9416 files for BUILD_JDK, an OutOfMemoryException will be thrown. By providing the "--with-memory-size=1024"option, configure will now specify that BOOT_JAVAC will be run with "-Xms400M -Xmx1100M". The astute will notice that -Xmx1100M is actually larger than physical RAM which is indeed correct. Which also means that swap space must be configured, and thrashing will take place during certain parts of the build. But hey, that's what was needed. Also note that these systems traditionally use SD cards as their sole filesystem. The thought of swapping to an SD card based disk sounds excruciating and it is. To alleviate somewhat, I attached a USB hard drive and located the build and swap space there. 3. Not sure the "--enable-openjdk-only" is needed. 5. Issued the following command to build: $ time make LOG=debug JOBS=4 images real 42m16.850s user 33m42.020s sys 4m42.970s Cheers, -- Jim C On 4/29/2014 12:34 PM, Jim Connors wrote: > Hello, > > Trying to build OpenJDK 8 for armhf, ultimately to be hosted on a > Raspberry Pi. I'm cross compiling from a Ubuntu 12.04 x86 Virtualbox > image and am using gcc-4.7-linaro-rpi-gnueabihf for a toolchain. > > Configuration invocation looks as follows: > > $ bash configure > --with-sys-root=/home/jimc/gcc-4.7-linaro-rpi-gnueabihf/ > --target=arm-unknown-linux-gnueabihf --with-jvm-variants=zero > --with-num-cores=2 > > The make fails like this: > > Compiling /home/jimc/openjdk8/hotspot/src/os/posix/vm/os_posix.cpp > /home/jimc/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp: In static > member function 'static jint os::init_2()': > /home/jimc/openjdk8/hotspot/src/os/linux/vm/os_linux.cpp:4853:42: > error: 'workaround_expand_exec_shield_cs_limit' was not declared in > this scope > > Might there a set of patches that are required to get this going > further? Anything else I'm missing? > > Any pointer greatly appreciated, > -- Jim C > > -- > > *Jim Connors,* Principal Sales Consultant > Oracle Alliances & Channels | Java Embedded Global Sales Unit > Office: +1 516.809.5925 > Cell: +1 516.782.5501 > Email: james.connors at oracle.com > > *Learn more about Embeddable Java:* > http://www.oracle.com/goto/javaembedded > From ivan at azulsystems.com Fri May 2 06:26:56 2014 From: ivan at azulsystems.com (Ivan Krylov) Date: Fri, 2 May 2014 08:26:56 +0200 Subject: Cross-building Windows binaries using the mingw toolchain In-Reply-To: References: <53610A59.9060102@redhat.com> <5361255C.4020406@redhat.com> Message-ID: <53633AB0.6080701@azulsystems.com> What would this give in practical terms? Suppose you are working on a cross-platform bug or feature. You want to make sure that the fix works on Windows as well. I would think that testing the fix with cross-compiled build would be insufficient for the reasons that Volker lists. If the produced bits aren't the same (and they won't be the same) we can not trust the results of such testing. And the test matrix for openjdk is already rather complex and making it even more complex with cross-compilation options will not help. And one still needs at least a virtualized copy of Windows to run tests anyways. I am not sure what is the status of Visual Studio Express support by the build chain but I'd rather see that in place as an alternative to the use of Visual Studio Professional.This way the produces jdk binaries will be much closer to the stock ones. Thanks, Ivan On 30/04/14 19:00 , Volker Simonis wrote: > On Wed, Apr 30, 2014 at 6:31 PM, Florian Weimer wrote: >> On 04/30/2014 06:16 PM, Volker Simonis wrote: >> >>> The first one is to make the OpenJDK compile on Windows with the MinGW >>> toolchain (instead of Cygwin). This currently doesn't work out of the >>> box but is relatively easy to achieve (see for example "8022177: >>> Windows/MSYS builds broken" >>> https://bugs.openjdk.java.net/browse/JDK-8022177). Magnus and I are >>> working on this (and actually I have an internal build which works >>> with MinGW). Hopefully we can fix this in the OpenJDK soon. >> >> Thanks for your input. If you say "MingW toolchain", you mean the scripting >> environment, but not the compiler and linker, right? >> >> >>> The second one is to cross compile the whole OpenJDK on Linux using >>> gcc and MingGW. If I understood you right that's what you actually >>> wanted. >> >> Yes, that's what I'm interested in. >> >> >>> I personally think that would be nice to have but at the same >>> >>> time I also think it would be quite hard to get there and probably not >>> worth doing it because even if you'd succeed nobody will probably >>> maintain it and it would break quite soon (see for example the >>> GCC/Solaris build or the Clang/Linux build). >> >> It's clear to me that this is worthwhile only if I set up a builder which >> detects bit rot quickly. >> >> >>> If you want to try it nevertheless, some of the problems you will face >>> will be at least the following ones: >>> - convert the HotSpot nmake makefiles to GNU syntax (notice that this >>> project is currently underway under the umbrella of the new build >>> system anyway, so you'd probably want to wait to avoid doing double >>> work) >> >> Ah, interesting. >> >> >>> - convert Visual Studio intrinsics, inline assembler and compiler >>> idiosyncrasies to GCC syntax >> >> Ahh, I wonder how much I will encounter there. That would be prerequisite >> for a pure-mingw build on Windows as well, right? >> >> >>> - you'll probably also need to cross compile dependencies like >>> libfreetype with GCC/MinGW >> >> Fedora already covers those, although the paths are somewhat unexpected. >> >> >>> - I'm actually not an expert, but the OpenJDK is linked against some >>> native Window libraries like DirectX and runtime libraries from the >>> Microsoft SDKs. I'm not an expert here and I don't know how that would >>> work for a cross-compile. >> >> We supposedly have the headers and import libraries in Fedora. >> >> >>> I personally think we should rather focus on further improving the >>> current Windows build. It's already a huge improvement compared to the >>> old JDK7 Windows build. From what I see, the main remaining problems >>> are to somehow make it possible to get a stable, defined and free >>> version of the Microsoft development tools which are "known to work". >> >> Yes, I tried to set up a Windows development environment, but quickly got >> confused. >> >> My background here is that I want to contribute some new features and I >> expect that feature parity for Windows will increase the likelihood of >> acceptance. >> > But why can't you install Cygwin and the free Microsoft Express/SDK > compilers and do a native build. From my experience that's a matter of > some hours (and you can find quite some documentation/tutorials/help > on the web and on the various mailing lists). Doing that you could be > sure that you really test what others (i.e. especially Oracle) will > get. Cross-compiling your new feature with a MinGW toolchain doesn't > mean that others will be able to compile and run that code with a > native Windows build tool chain (it would be actually quite easy to > introduce changes which work for the MinGW cross-build but break for > the native build) So I don't see how that would increase the > confidence in your change. > > From my experience, native OpenJDK changes (and often even trivial > ones) should be build and tested at least on Linux and Windows (this > already exercises your changes on two different OSs with two different > compilers). Bigger shared changes should also be tested on MacOS X > (which is quite "cheap" and gives you a third OS and compiler) and > Solaris (which is hard nowadays). > >> I need to think about it, but for my purposes, a pure mingw environment >> running on Windows would work as well. It would be less specialized, so >> perhaps there is more interest in that. >> >> >> -- >> Florian Weimer / Red Hat Product Security Team From staffan.larsen at oracle.com Fri May 2 06:53:26 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 2 May 2014 08:53:26 +0200 Subject: Proposal: jtreg tests with native components In-Reply-To: <5361DF8D.5010800@oracle.com> References: <5360C4EB.80201@oracle.com> <6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com> <5361DF8D.5010800@oracle.com> Message-ID: <69D2F327-937E-4C4F-B8C7-8D75059D89E6@oracle.com> On 1 maj 2014, at 07:45, David Holmes wrote: > On 30/04/2014 9:39 PM, Staffan Larsen wrote: >> >> On 30 apr 2014, at 11:39, David Holmes wrote: >> >>> Hi Staffan, >>> >>> On 25/04/2014 10:02 PM, Staffan Larsen wrote: >>>> There are a couple of jtreg tests today that depend on native components (either JNI libraries or executables). These are handled in one of two ways: >>>> >>>> 1) The binaries are pre-compiled and checked into the repository (often inside jar files). >>>> 2) The test will try to invoke a compiler (gcc, cl, ?) when the test is being run. >>>> >>>> Neither of these are very good solutions. #1 makes it hard to run the setup the test for all platforms and requires binaries in the source control system. #2 is hit-and-miss: the correct compiler may or may not be installed on the test machine, and the approach requires platform specific logic to be maintained. >>> >>> #2 is far from perfect but ... >>> >>>> I would like to propose that these native components are instead compiled when the product is built by the same makefile logic as the product. At product build time we know we have access to the (correct) compilers and we have excellent support in the makefiles for building on all platforms. >>>> >>>> If we build the native test components together with the product, we also have to take care of distributing the result together with the product when we do testing across a larger number of machines. We will also need a way to tell the jtreg tests where these pre-built binaries are located. >>> >>> don't under estimate the complexity involved in building then "distributing" the test binaries. >> >> I don?t. It will be complicated, but I?m sure we can do it. > > The question is whether it is worth it relative to the size of the problem. I think we will see a large influx of these kinds of tests, especially in the hotspot repo. > >>> >>> You will still need to maintain platform specific logic as you won't necessarily be able to use the CFLAGS etc that the main build process uses. >> >> Can you explain more? Why can?t I use CFLAGS as it is? > > You _may_ be able to, you may not. I know we already had issues where the CFLAGS as being used for the JDK sources also got applied to building the code-generator utility programs and that didn't work correctly. Here's sample CFLAGS from a JDK build > > CFLAGS_JDKLIB:= -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 -DRELEASE='"$(RELEASE)"' -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include/linux -I/export/users/dh198349/jdk8u-dev/jdk/src/share/javavm/export -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/javavm/export -I/export/users/dh198349/jdk8u-dev/jdk/src/share/native/common -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/native/common -m32 -fno-strict-aliasing -fPIC > > Does that make sense for compiling a test? Does it depend on whether we are building a native library or a native executable? I think they make sense, at least initially. If not, we can tune them, but that "tuning? will be in one central location and not spread out in a lot of shell scripts. I also plan to allow individual tests to override the flags if necessary (for example to link with X11). For executables there is CFLAGS_JDKEXE. Thanks, /Staffan > >>> >>> Also talk to SQE as I'm pretty sure there is an existing project to look at how to better handle this, at least for the internal test suites. >> >> I have talked to SQE. I don?t know of any other projects to handle this. > > :) It wasn't SQE, it was your project as referenced in a few bug reports last August/September. > > David > > >> /Staffan >> >> >>> >>> David >>> ----- >>> >>>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started. >>>> >>>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components. >>>> >>>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository. >>>> >>>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such. >>>> >>>> Thanks, >>>> /Staffan >>>> >> From fweimer at redhat.com Fri May 2 14:07:08 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 02 May 2014 16:07:08 +0200 Subject: Cross-building Windows binaries using the mingw toolchain In-Reply-To: <53633AB0.6080701@azulsystems.com> References: <53610A59.9060102@redhat.com> <5361255C.4020406@redhat.com> <53633AB0.6080701@azulsystems.com> Message-ID: <5363A68C.1030406@redhat.com> On 05/02/2014 08:26 AM, Ivan Krylov wrote: > Suppose you are working on a > cross-platform bug or feature. You want to make sure that the fix works > on Windows as well. I would think that testing the fix with > cross-compiled build would be insufficient for the reasons that Volker > lists. If the produced bits aren't the same (and they won't be the same) > we can not trust the results of such testing. Even with native tools, the builds do not match what others will end up with. I generally won't test with the patches downstream distributions use, especially those who have closed patches, and there are also quite significant differences in compiler versions and build environment. This isn't really specific to OpenJDK?you can often avoid such issues by not going all too crazy with boundary conditions etc. Would building with mingw64 make things worse? Could be, but we don't really know at this point. -- Florian Weimer / Red Hat Product Security Team From fweimer at redhat.com Fri May 2 14:19:29 2014 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 02 May 2014 16:19:29 +0200 Subject: Cross-building Windows binaries using the mingw toolchain In-Reply-To: References: <53610A59.9060102@redhat.com> <5361255C.4020406@redhat.com> Message-ID: <5363A971.6080804@redhat.com> On 04/30/2014 07:00 PM, Volker Simonis wrote: > But why can't you install Cygwin and the free Microsoft Express/SDK > compilers and do a native build. I finally got it to work. When running on 64-bit Windows, you have to specify --with-target-bits=32, otherwise building with Visual Studio Express will fail. It's obvious in retrospect, but somewhat difficult to figure out, considering that ./configure explicitly ignores the failure to locate the 64-bit environment variables file from Visual Studio. All in all, it's relatively painless, so I will stick with that for the time being. (I'm not actually eager to spend time on Windows-only enhancements, anyway.) > Doing that you could be > sure that you really test what others (i.e. especially Oracle) will > get. See my reply to Ivan. I have no illusions that my non-cross environments are very close to anything anyone uses to build supported binaries. At some level, this sucks, but that's life with heavily patched or proprietary downstreams. -- Florian Weimer / Red Hat Product Security Team From mike.duigou at oracle.com Sun May 4 03:24:06 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 3 May 2014 20:24:06 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <531F05D3.6020008@oracle.com> References: <531F05D3.6020008@oracle.com> Message-ID: Hello; Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. https://bugs.openjdk.java.net/browse/JDK-8032045 http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ Mike On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: > On 2014-03-11 00:49, Mike Duigou wrote: >> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >> >> https://bugs.openjdk.java.net/browse/JDK-8032045 >> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >> >> This version is, hopefully, almost ready to be pushed. > > I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. > > The top-level build changes looks fine. Thank you Mike for cleaning things up! > > /Magnus > >> >> Mike >> >> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >> >>> Hello all; >>> >>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>> >>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>> >>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>> >>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>> >>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>> >>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>> >>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>> >>> Thanks, >>> >>> Mike > From lhochet at gmail.com Sun May 4 18:50:56 2014 From: lhochet at gmail.com (Ludovic HOCHET) Date: Sun, 4 May 2014 20:50:56 +0200 Subject: Cross-building Windows binaries using the mingw toolchain In-Reply-To: <5363A971.6080804@redhat.com> References: <53610A59.9060102@redhat.com> <5361255C.4020406@redhat.com> <5363A971.6080804@redhat.com> Message-ID: On Fri, May 2, 2014 at 4:19 PM, Florian Weimer wrote: > On 04/30/2014 07:00 PM, Volker Simonis wrote: > >> But why can't you install Cygwin and the free Microsoft Express/SDK >> compilers and do a native build. > > > I finally got it to work. When running on 64-bit Windows, you have to > specify --with-target-bits=32, otherwise building with Visual Studio Express > will fail. It's obvious in retrospect, but somewhat difficult to figure > out, considering that ./configure explicitly ignores the failure to locate > the 64-bit environment variables file from Visual Studio. For 64bits you need to also install the Windows SDK [1], from a blog post by Volker [2] VS Express does not include all the necessary stuff for 64bits. [1] http://www.microsoft.com/en-us/download/details.aspx?id=8279 [2] https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction > > All in all, it's relatively painless, so I will stick with that for the time > being. (I'm not actually eager to spend time on Windows-only enhancements, > anyway.) > > >> Doing that you could be >> sure that you really test what others (i.e. especially Oracle) will >> get. > > > See my reply to Ivan. I have no illusions that my non-cross environments > are very close to anything anyone uses to build supported binaries. At some > level, this sucks, but that's life with heavily patched or proprietary > downstreams. > > > -- > Florian Weimer / Red Hat Product Security Team -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From erik.joelsson at oracle.com Mon May 5 09:23:35 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 05 May 2014 11:23:35 +0200 Subject: Proposal: jtreg tests with native components In-Reply-To: <69D2F327-937E-4C4F-B8C7-8D75059D89E6@oracle.com> References: <5360C4EB.80201@oracle.com> <6D79B1FC-EEDA-497B-B622-D791D89E0DD3@oracle.com> <5361DF8D.5010800@oracle.com> <69D2F327-937E-4C4F-B8C7-8D75059D89E6@oracle.com> Message-ID: <53675897.7040205@oracle.com> On 2014-05-02 08:53, Staffan Larsen wrote: > On 1 maj 2014, at 07:45, David Holmes wrote: > >> On 30/04/2014 9:39 PM, Staffan Larsen wrote: >> The question is whether it is worth it relative to the size of the >> problem. > I think we will see a large influx of these kinds of tests, especially in the hotspot repo. I don't doubt it will be worth it. >>>> You will still need to maintain platform specific logic as you won't necessarily be able to use the CFLAGS etc that the main build process uses. >>> Can you explain more? Why can?t I use CFLAGS as it is? >> You _may_ be able to, you may not. I know we already had issues where the CFLAGS as being used for the JDK sources also got applied to building the code-generator utility programs and that didn't work correctly. Here's sample CFLAGS from a JDK build >> >> CFLAGS_JDKLIB:= -W -Wall -Wno-unused -Wno-parentheses -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 -DRELEASE='"$(RELEASE)"' -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include/linux -I/export/users/dh198349/jdk8u-dev/jdk/src/share/javavm/export -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/javavm/export -I/export/users/dh198349/jdk8u-dev/jdk/src/share/native/common -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/native/common -m32 -fno-strict-aliasing -fPIC >> >> Does that make sense for compiling a test? Does it depend on whether we are building a native library or a native executable? > I think they make sense, at least initially. If not, we can tune them, but that "tuning? will be in one central location and not spread out in a lot of shell scripts. I also plan to allow individual tests to override the flags if necessary (for example to link with X11). > > For executables there is CFLAGS_JDKEXE. For the initial proof of concept, just using the existing CFLAGS_JDKLIB and CFLAGS_JDKEXE will be fine. Going forward, I would like to see CFLAGS_TESTLIB and CFLAGS_TESTEXE being provided by configure. There will certainly be a lot of common things for both product and test libs and as pointed out above, some differences too. We should leverage the logic already present in our configure script to provide suitable defaults. /Erik > Thanks, > /Staffan > >>>> Also talk to SQE as I'm pretty sure there is an existing project to look at how to better handle this, at least for the internal test suites. >>> I have talked to SQE. I don?t know of any other projects to handle this. >> :) It wasn't SQE, it was your project as referenced in a few bug reports last August/September. >> >> David >> >> >>> /Staffan >>> >>> >>>> David >>>> ----- >>>> >>>>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started. >>>>> >>>>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it?s native components. >>>>> >>>>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository. >>>>> >>>>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> From erik.joelsson at oracle.com Mon May 5 13:28:06 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 05 May 2014 15:28:06 +0200 Subject: RFR: JDK-8042348: Copyright link in Javadoc page for Java SE 8 Message-ID: <536791E6.10104@oracle.com> Hello, Please review this small patch to javadoc generation. The Copyright footer, at the bottom of the page, should be a link, but in jdk8 and 9 it isn't. This is caused by COPYRIGHT_URL being empty if JDK_MINOR_VERSION is not 7. I see no reason to have a jdk version dependency on this URL since the value isn't dependent on jdk version. This will likely need a backport to 8 too. Bug: https://bugs.openjdk.java.net/browse/JDK-8042348 Patch inline: diff -r 183052721803 make/Javadoc.gmk --- a/make/Javadoc.gmk +++ b/make/Javadoc.gmk @@ -115,10 +115,7 @@ DOCSDIR_URL = {@docroot}/$(GET2DOCSDIR) # Url to copyright html file -COPYRIGHT_URL-7 = $(DOCSDIR_URL)/legal/cpyr.html -# This isn't added in old build yet. -#COPYRIGHT_URL-8 = $(DOCSDIR_URL)/legal/cpyr.html -COPYRIGHT_URL = $(COPYRIGHT_URL-$(JDK_MINOR_VERSION)) +COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html # Url to bug filing site From tim.bell at oracle.com Mon May 5 13:37:04 2014 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 05 May 2014 13:37:04 +0000 Subject: RFR: JDK-8042348: Copyright link in Javadoc page for Java SE 8 In-Reply-To: <536791E6.10104@oracle.com> References: <536791E6.10104@oracle.com> Message-ID: <53679400.3090603@oracle.com> Hello Erik: > Please review this small patch to javadoc generation. The Copyright > footer, at the bottom of the page, should be a link, but in jdk8 and 9 > it isn't. This is caused by COPYRIGHT_URL being empty if > JDK_MINOR_VERSION is not 7. I see no reason to have a jdk version > dependency on this URL since the value isn't dependent on jdk version. > > This will likely need a backport to 8 too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042348 > Patch inline: > diff -r 183052721803 make/Javadoc.gmk > --- a/make/Javadoc.gmk > +++ b/make/Javadoc.gmk > @@ -115,10 +115,7 @@ > DOCSDIR_URL = {@docroot}/$(GET2DOCSDIR) > > # Url to copyright html file > -COPYRIGHT_URL-7 = $(DOCSDIR_URL)/legal/cpyr.html > -# This isn't added in old build yet. > -#COPYRIGHT_URL-8 = $(DOCSDIR_URL)/legal/cpyr.html > -COPYRIGHT_URL = $(COPYRIGHT_URL-$(JDK_MINOR_VERSION)) > +COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html Looks good to me. /Tim From mike.duigou at oracle.com Mon May 5 17:54:32 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 5 May 2014 10:54:32 -0700 Subject: RFR: JDK-8042417 : (s) hgforest: allow local clone of extra repos Message-ID: Hello all; This is a small enhancement to hgforest.sh cloning which will include cloning the extra repos if they exist. https://bugs.openjdk.java.net/browse/JDK-8042417 http://cr.openjdk.java.net/~mduigou/JDK-8042417/0/webrev/ This feature was requested by a user who has been doing file copies instead of cloning because the extra repos weren't being copied. Mike From iris.clark at oracle.com Mon May 5 18:11:12 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 5 May 2014 11:11:12 -0700 (PDT) Subject: RFR: JDK-8042348: Copyright link in Javadoc page for Java SE 8 In-Reply-To: <536791E6.10104@oracle.com> References: <536791E6.10104@oracle.com> Message-ID: <6cb5dbd5-cee5-408b-aba6-915fa9bea9ff@default> Hi, Erik. I think the change looks fine. Thanks, iris -----Original Message----- From: Erik Joelsson Sent: Monday, May 05, 2014 6:28 AM To: build-dev Subject: RFR: JDK-8042348: Copyright link in Javadoc page for Java SE 8 Hello, Please review this small patch to javadoc generation. The Copyright footer, at the bottom of the page, should be a link, but in jdk8 and 9 it isn't. This is caused by COPYRIGHT_URL being empty if JDK_MINOR_VERSION is not 7. I see no reason to have a jdk version dependency on this URL since the value isn't dependent on jdk version. This will likely need a backport to 8 too. Bug: https://bugs.openjdk.java.net/browse/JDK-8042348 Patch inline: diff -r 183052721803 make/Javadoc.gmk --- a/make/Javadoc.gmk +++ b/make/Javadoc.gmk @@ -115,10 +115,7 @@ DOCSDIR_URL = {@docroot}/$(GET2DOCSDIR) # Url to copyright html file -COPYRIGHT_URL-7 = $(DOCSDIR_URL)/legal/cpyr.html -# This isn't added in old build yet. -#COPYRIGHT_URL-8 = $(DOCSDIR_URL)/legal/cpyr.html -COPYRIGHT_URL = $(COPYRIGHT_URL-$(JDK_MINOR_VERSION)) +COPYRIGHT_URL = $(DOCSDIR_URL)/legal/cpyr.html # Url to bug filing site From chris.hegarty at oracle.com Tue May 6 08:06:11 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 May 2014 09:06:11 +0100 Subject: RFR: JDK-8042417 : (s) hgforest: allow local clone of extra repos In-Reply-To: References: Message-ID: <876F8E82-8810-42C4-992F-14997FE7CC47@oracle.com> This looks like a nice addition Mike. -Chris. On 5 May 2014, at 18:54, Mike Duigou wrote: > Hello all; > > This is a small enhancement to hgforest.sh cloning which will include cloning the extra repos if they exist. > > https://bugs.openjdk.java.net/browse/JDK-8042417 > http://cr.openjdk.java.net/~mduigou/JDK-8042417/0/webrev/ > > This feature was requested by a user who has been doing file copies instead of cloning because the extra repos weren't being copied. > > Mike From erik.joelsson at oracle.com Tue May 6 08:26:53 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 06 May 2014 10:26:53 +0200 Subject: RFR: JDK-8042417 : (s) hgforest: allow local clone of extra repos In-Reply-To: References: Message-ID: <53689CCD.6060600@oracle.com> Looks good to me. /Erik On 2014-05-05 19:54, Mike Duigou wrote: > Hello all; > > This is a small enhancement to hgforest.sh cloning which will include cloning the extra repos if they exist. > > https://bugs.openjdk.java.net/browse/JDK-8042417 > http://cr.openjdk.java.net/~mduigou/JDK-8042417/0/webrev/ > > This feature was requested by a user who has been doing file copies instead of cloning because the extra repos weren't being copied. > > Mike From fweimer at redhat.com Tue May 6 14:30:13 2014 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 06 May 2014 16:30:13 +0200 Subject: Cross-building Windows binaries using the mingw toolchain In-Reply-To: References: <53610A59.9060102@redhat.com> <5361255C.4020406@redhat.com> <5363A971.6080804@redhat.com> Message-ID: <5368F1F5.7050803@redhat.com> On 05/04/2014 08:50 PM, Ludovic HOCHET wrote: >> I finally got it to work. When running on 64-bit Windows, you have to >> specify --with-target-bits=32, otherwise building with Visual Studio Express >> will fail. It's obvious in retrospect, but somewhat difficult to figure >> out, considering that ./configure explicitly ignores the failure to locate >> the 64-bit environment variables file from Visual Studio. > For 64bits you need to also install the Windows SDK [1], from a blog > post by Volker [2] VS Express does not include all the necessary stuff > for 64bits. > > [1] http://www.microsoft.com/en-us/download/details.aspx?id=8279 > [2] https://weblogs.java.net/blog/simonis/archive/2011/10/28/yaojowbi-yet-another-openjdk-windows-build-instruction It's always a bit difficult to tell if build instructions from three years ago are still valid. I'll keep those resources in mind and try them once I need building on 64 bit. Thanks. -- Florian Weimer / Red Hat Product Security Team From rajan.halade at oracle.com Tue May 6 21:32:57 2014 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 06 May 2014 14:32:57 -0700 Subject: OpenJDK 9 build with OS X 10.9.2 Message-ID: <53695509.2080309@oracle.com> Hi, I appreciate any help on this! I am having issue building OpenJDK 9 on Mac OSx 10.9.2. I am using - GNU Make 3.81 stable jdk 8 Xcode 4.6.2 Xquartz 2.7.5 The build process doesn't progress (stuck) building hotspot after - Making SA debugger back-end... warning: (x86_64) /var/folders/jx/r5jpky9d7g34l1tkbs0s48cw0000gn/T//ccIgleYw.o unable to open object file warning: no debug symbols in executable (-arch x86_64) Compiling /Users/rhalade/work/repos/openjdk9/dev/hotspot/src/share/vm/runtime/vm_version.cpp warning: (x86_64) /var/folders/jx/r5jpky9d7g34l1tkbs0s48cw0000gn/T//ccgFGfRL.o unable to open object file warning: (x86_64) /var/folders/jx/r5jpky9d7g34l1tkbs0s48cw0000gn/T//cccrJV3N.o unable to open object file warning: (x86_64) /var/folders/jx/r5jpky9d7g34l1tkbs0s48cw0000gn/T//cc4gPUmA.o unable to open object file warning: (x86_64) /var/folders/jx/r5jpky9d7g34l1tkbs0s48cw0000gn/T//cchOC73J.o unable to open object file warning: (x86_64) /var/folders/jx/r5jpky9d7g34l1tkbs0s48cw0000gn/T//cce3dtLk.o unable to open object file warning: no debug symbols in executable (-arch x86_64) Linking vm... Doing vm.make build: All done. INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 No compiler1 (fastdebug1) for ARCH_DATA_MODEL=64 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning Generating bsd_amd64_docs/jvmti.html INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 Let me know if you require config/build log files to be emailed. Thanks, Rajan From mikael.vidstedt at oracle.com Wed May 7 01:14:42 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 06 May 2014 18:14:42 -0700 Subject: Appreciations of the new build system Message-ID: <53698902.3070507@oracle.com> All, A somewhat belated, but highly deserved thank you to everybody who spent time and energy on putting together the new build system. The new build system is fast, fascinatingly easy to use and doesn't surprise its users - in short, it Just Works(tm). That fact, btw, becomes even more obvious if you ever have to work with the old build system... You all deserve some significant virtual points - I +1 / upvote you all! That is all. Thanks, Mikael From pointo1d at gmail.com Wed May 7 16:27:35 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 7 May 2014 17:27:35 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot Message-ID: Hi , Although having to resort to the use of a different e-mail address, JIC the sig doesn't give it away :-), I'm back on the trail of adapting the OJDK build to selectively use the IBM JVM together with modifying the IBM build to better incorporate the autoconf based approach in a manner that will prove beneficial to all. I now crave your indulgence for consideration of what I believe to be a self-contained & thus no webrev, enhancement to the build system as completely identified in https://bugs.openjdk.java.net/browse/JDK-8037953... TIA and rgds to all, -- 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 From pointo1d at gmail.com Wed May 7 17:18:19 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 7 May 2014 18:18:19 +0100 Subject: No subject Message-ID: Greetings fellow builders , I have a question, as the subject suggests, regarding the version of the nashorn repo - specifically, one of my current tasks is to attempt to build OJDK level jdk8-b73 but I can't find that level/tag in the nashorn repo. Is there a usual or even standard, method used in OJDK to establish the appropriate level of sub-repos ? TIA & 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 From david.katleman at oracle.com Wed May 7 17:57:27 2014 From: david.katleman at oracle.com (David Katleman) Date: Wed, 07 May 2014 10:57:27 -0700 Subject: jdk8-b73 & nashorn In-Reply-To: References: Message-ID: <536A7407.5060309@oracle.com> On 5/7/2014 10:18 AM, Dave Pointon wrote: > Greetings fellow builders , > > I have a question, as the subject suggests, regarding the version of the > nashorn repo - specifically, one of my current tasks is to attempt to build > OJDK level jdk8-b73 but I can't find that level/tag in the nashorn repo. > > Is there a usual or even standard, method used in OJDK to establish the > appropriate level of sub-repos ? nashorn wasn't added to JDK 8 until about b82, so earlier tags wouldn't be there. Looks like the creator of nashorn did add some older tags to the repo to help out in situations like this, but b73 was omitted In this case, you could use jdk8-b69, and you would get the same as what you would get for b73, which is nothing, since nashorn was still empty. Thanks Dave From pointo1d at gmail.com Wed May 7 18:00:29 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 7 May 2014 19:00:29 +0100 Subject: jdk8-b73 & nashorn In-Reply-To: <536A7407.5060309@oracle.com> References: <536A7407.5060309@oracle.com> Message-ID: Thanx for the fast response, Dave - reply duly noted and indeed promulgated :-) Thanx again , -- 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 7 May 2014 18:57, David Katleman wrote: > > On 5/7/2014 10:18 AM, Dave Pointon wrote: > >> Greetings fellow builders , >> >> I have a question, as the subject suggests, regarding the version of the >> nashorn repo - specifically, one of my current tasks is to attempt to >> build >> OJDK level jdk8-b73 but I can't find that level/tag in the nashorn repo. >> >> Is there a usual or even standard, method used in OJDK to establish the >> appropriate level of sub-repos ? >> > > nashorn wasn't added to JDK 8 until about b82, so earlier tags wouldn't be > there. > > Looks like the creator of nashorn did add some older tags to the repo to > help out in situations like this, but b73 was omitted > > In this case, you could use jdk8-b69, and you would get the same as what > you would get for b73, which is nothing, since nashorn was still empty. > > Thanks > Dave > From pointo1d at gmail.com Wed May 7 18:18:25 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 7 May 2014 19:18:25 +0100 Subject: jdk8-b73 & nashorn In-Reply-To: References: <536A7407.5060309@oracle.com> Message-ID: ... having said that though, with the benefit of a little hindsight and the application of not a little CM common sense, isn't there a shortfall in Mercurial in as much as I would expect an update to b73 to remove nashorn as a sub-repo from the forest since it wasn't present when the tag was created ... or is it me ? -- 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 7 May 2014 19:00, Dave Pointon wrote: > Thanx for the fast response, Dave - reply duly noted and indeed > promulgated :-) > > Thanx again , > > -- > 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 7 May 2014 18:57, David Katleman wrote: > >> >> On 5/7/2014 10:18 AM, Dave Pointon wrote: >> >>> Greetings fellow builders , >>> >>> I have a question, as the subject suggests, regarding the version of the >>> nashorn repo - specifically, one of my current tasks is to attempt to >>> build >>> OJDK level jdk8-b73 but I can't find that level/tag in the nashorn repo. >>> >>> Is there a usual or even standard, method used in OJDK to establish the >>> appropriate level of sub-repos ? >>> >> >> nashorn wasn't added to JDK 8 until about b82, so earlier tags wouldn't >> be there. >> >> Looks like the creator of nashorn did add some older tags to the repo to >> help out in situations like this, but b73 was omitted >> >> In this case, you could use jdk8-b69, and you would get the same as what >> you would get for b73, which is nothing, since nashorn was still empty. >> >> Thanks >> Dave >> > > From david.katleman at oracle.com Wed May 7 18:29:02 2014 From: david.katleman at oracle.com (David Katleman) Date: Wed, 07 May 2014 11:29:02 -0700 Subject: jdk8-b73 & nashorn In-Reply-To: References: <536A7407.5060309@oracle.com> Message-ID: <536A7B6E.6060001@oracle.com> On 5/7/2014 11:18 AM, Dave Pointon wrote: > ... having said that though, with the benefit of a little hindsight > and the application of not a little CM common sense, isn't there a > shortfall in Mercurial in as much as I would expect an update to b73 > to remove nashorn as a sub-repo from the forest since it wasn't > present when the tag was created ... or is it me ? Update to b73 implies you are coming from an earlier build of the JDK 8 forest, where nashorn also does not exist as well. Mercurial doesn't know of nashorn's existence yet. If you have a later build of the JDK 8 forest, you are better off with a new clone, rather than expecting mercurial will downgrade your repos. I would not want mecurial removing my new repos I've just created within my forest, if I happen to do a pull from a forest that didn't have my new repo. Dave > > -- > 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 7 May 2014 19:00, Dave Pointon > wrote: > > Thanx for the fast response, Dave - reply duly noted and indeed > promulgated :-) > > Thanx again , > > -- > 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 7 May 2014 18:57, David Katleman > wrote: > > > On 5/7/2014 10:18 AM, Dave Pointon wrote: > > Greetings fellow builders , > > I have a question, as the subject suggests, regarding the > version of the > nashorn repo - specifically, one of my current tasks is to > attempt to build > OJDK level jdk8-b73 but I can't find that level/tag in the > nashorn repo. > > Is there a usual or even standard, method used in OJDK to > establish the > appropriate level of sub-repos ? > > > nashorn wasn't added to JDK 8 until about b82, so earlier tags > wouldn't be there. > > Looks like the creator of nashorn did add some older tags to > the repo to help out in situations like this, but b73 was omitted > > In this case, you could use jdk8-b69, and you would get the > same as what you would get for b73, which is nothing, since > nashorn was still empty. > > Thanks > Dave > > > From pointo1d at gmail.com Wed May 7 18:35:48 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 7 May 2014 19:35:48 +0100 Subject: jdk8-b73 & nashorn In-Reply-To: <536A7B6E.6060001@oracle.com> References: <536A7407.5060309@oracle.com> <536A7B6E.6060001@oracle.com> Message-ID: Hmmm, it was indeed originated as a new clone immediately followed by an 'update -r jdk8-b73' to take it back to the previous level, or so I thought. You can probably tell that I was under the impression that the commands 'clone -r level' and 'clone && update -r level' were equivalent ... self-evidently not. Very many thanx for your forebearance in being a sounding board. -- 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 7 May 2014 19:29, David Katleman wrote: > > On 5/7/2014 11:18 AM, Dave Pointon wrote: > > ... having said that though, with the benefit of a little hindsight and > the application of not a little CM common sense, isn't there a shortfall in > Mercurial in as much as I would expect an update to b73 to remove nashorn > as a sub-repo from the forest since it wasn't present when the tag was > created ... or is it me ? > > > Update to b73 implies you are coming from an earlier build of the JDK 8 > forest, where nashorn also does not exist as well. Mercurial doesn't know > of nashorn's existence yet. > > If you have a later build of the JDK 8 forest, you are better off with a > new clone, rather than expecting mercurial will downgrade your repos. I > would not want mecurial removing my new repos I've just created within my > forest, if I happen to do a pull from a forest that didn't have my new > repo. > > Dave > > > > > -- > 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 7 May 2014 19:00, Dave Pointon wrote: > >> Thanx for the fast response, Dave - reply duly noted and indeed >> promulgated :-) >> >> Thanx again , >> >> -- >> 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 7 May 2014 18:57, David Katleman wrote: >> >>> >>> On 5/7/2014 10:18 AM, Dave Pointon wrote: >>> >>>> Greetings fellow builders , >>>> >>>> I have a question, as the subject suggests, regarding the version of the >>>> nashorn repo - specifically, one of my current tasks is to attempt to >>>> build >>>> OJDK level jdk8-b73 but I can't find that level/tag in the nashorn repo. >>>> >>>> Is there a usual or even standard, method used in OJDK to establish the >>>> appropriate level of sub-repos ? >>>> >>> >>> nashorn wasn't added to JDK 8 until about b82, so earlier tags wouldn't >>> be there. >>> >>> Looks like the creator of nashorn did add some older tags to the repo to >>> help out in situations like this, but b73 was omitted >>> >>> In this case, you could use jdk8-b69, and you would get the same as what >>> you would get for b73, which is nothing, since nashorn was still empty. >>> >>> Thanks >>> Dave >>> >> >> > > From erik.joelsson at oracle.com Thu May 8 07:56:55 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 08 May 2014 09:56:55 +0200 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: References: Message-ID: <536B38C7.70800@oracle.com> Hello Dave, Adding this information certainly makes sense. While probably not a very common usecase, it is currently possible to point "--with-import-hotspot" to the dist directory of a Hotspot build. The problem then is that there will be no java launcher present to query for version information. Could you please add a condition on the existance of $with_import_hotspot/bin/java before trying to run it? If it's not there, the version will simply be unknown. The patch looks like it's missing indentation. This might be because of formatting in JIRA, but in case it's not, please indent the if statements properly with 2 spaces. /Erik On 2014-05-07 18:27, Dave Pointon wrote: > Hi , > > Although having to resort to the use of a different e-mail address, JIC the > sig doesn't give it away :-), I'm back on the trail of adapting the OJDK > build to selectively use the IBM JVM together with modifying the IBM build > to better incorporate the autoconf based approach in a manner that will > prove beneficial to all. > > I now crave your indulgence for consideration of what I believe to be a > self-contained & thus no webrev, enhancement to the build system as > completely identified in https://bugs.openjdk.java.net/browse/JDK-8037953... > > TIA and rgds to all, > > -- > 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 From david.holmes at oracle.com Thu May 8 09:57:31 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 May 2014 19:57:31 +1000 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536B38C7.70800@oracle.com> References: <536B38C7.70800@oracle.com> Message-ID: <536B550B.7080809@oracle.com> On 8/05/2014 5:56 PM, Erik Joelsson wrote: > Hello Dave, > > Adding this information certainly makes sense. While probably not a very > common usecase, it is currently possible to point > "--with-import-hotspot" to the dist directory of a Hotspot build. The > problem then is that there will be no java launcher present to query for > version information. Could you please add a condition on the existance > of $with_import_hotspot/bin/java before trying to run it? If it's not > there, the version will simply be unknown. This also needs to account for cross-compilation builds. You can't execute the imported java then either. Overall I'm not sure this change carries its weight. If you point configure to a particular imported component, why should you expect configure to tell you about the component you picked? David H. -------- > The patch looks like it's missing indentation. This might be because of > formatting in JIRA, but in case it's not, please indent the if > statements properly with 2 spaces. > > /Erik > > On 2014-05-07 18:27, Dave Pointon wrote: >> Hi , >> >> Although having to resort to the use of a different e-mail address, >> JIC the >> sig doesn't give it away :-), I'm back on the trail of adapting the OJDK >> build to selectively use the IBM JVM together with modifying the IBM >> build >> to better incorporate the autoconf based approach in a manner that will >> prove beneficial to all. >> >> I now crave your indulgence for consideration of what I believe to be a >> self-contained & thus no webrev, enhancement to the build system as >> completely identified in >> https://bugs.openjdk.java.net/browse/JDK-8037953... >> >> TIA and rgds to all, >> >> -- >> 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 > From pointo1d at gmail.com Thu May 8 11:55:45 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Thu, 8 May 2014 12:55:45 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536B38C7.70800@oracle.com> References: <536B38C7.70800@oracle.com> Message-ID: Hi Erik , Thanx for that, bizarrely, I never even considered that JIRA might choose to apply a little re-formatting but it undoubtedly has. Anyway, I'm a not little uncertain of your assertion 'The problem then is that there will be no java launcher present to query for version information' - would you happen to know if there is a definition of the (expected) contents of a hotspot build - as you can probably tell, I rather assumed that a bin directory (and indeed bin/java) would be in there. ?TIA & 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 8 May 2014 08:56, Erik Joelsson wrote: > Hello Dave, > > Adding this information certainly makes sense. While probably not a very > common usecase, it is currently possible to point "--with-import-hotspot" > to the dist directory of a Hotspot build. The problem then is that there > will be no java launcher present to query for version information. Could > you please add a condition on the existance of > $with_import_hotspot/bin/java before trying to run it? If it's not there, > the version will simply be unknown. > > The patch looks like it's missing indentation. This might be because of > formatting in JIRA, but in case it's not, please indent the if statements > properly with 2 spaces. > > /Erik > ? > From erik.joelsson at oracle.com Thu May 8 13:03:46 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 08 May 2014 15:03:46 +0200 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: References: <536B38C7.70800@oracle.com> Message-ID: <536B80B2.6040408@oracle.com> Hello, On 2014-05-08 13:55, Dave Pointon wrote: > Hi Erik , > > Thanx for that, bizarrely, I never even considered that JIRA might > choose to apply a little re-formatting but it undoubtedly has. > > Anyway, I'm a not little uncertain of your assertion 'The problem then > is that there will be no java launcher present to query for version > information' - would you happen to know if there is a definition of > the (expected) contents of a hotspot build - as you can probably tell, > I rather assumed that a bin directory (and indeed bin/java) would be > in there. > If you build hotspot, look what it produces in the dist sub directory in the build output. David Holmes also has a valid point. The bin/java in the imported hotspot might not even be runnable if we are cross compiling. In that case we also need to refrain from trying to run it. /Erik > ?TIA & 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 8 May 2014 08:56, Erik Joelsson > wrote: > > Hello Dave, > > Adding this information certainly makes sense. While probably not > a very common usecase, it is currently possible to point > "--with-import-hotspot" to the dist directory of a Hotspot build. > The problem then is that there will be no java launcher present to > query for version information. Could you please add a condition on > the existance of $with_import_hotspot/bin/java before trying to > run it? If it's not there, the version will simply be unknown. > > The patch looks like it's missing indentation. This might be > because of formatting in JIRA, but in case it's not, please indent > the if statements properly with 2 spaces. > > /Erik > ? > From pointo1d at gmail.com Thu May 8 13:42:51 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Thu, 8 May 2014 14:42:51 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536B80B2.6040408@oracle.com> References: <536B38C7.70800@oracle.com> <536B80B2.6040408@oracle.com> Message-ID: Ah OK, thanx for the tip, Erik, never thought of that [building hotspot] either - my, oh my, what a weeks it's been ... and it's not over yet by a long chalk. I only asked because of the observation that David made and you re-iterated - I just wondered if there might be a properties file, or similar, from which the version info could be gleaned since there appears to be a jvm.cmptag in the IBM JVM that I'm trying to use for the build. -- 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 8 May 2014 14:03, Erik Joelsson wrote: > Hello, > > > On 2014-05-08 13:55, Dave Pointon wrote: > > Hi Erik , > > Thanx for that, bizarrely, I never even considered that JIRA might > choose to apply a little re-formatting but it undoubtedly has. > > Anyway, I'm a not little uncertain of your assertion 'The problem then is > that there will be no java launcher present to query for version > information' - would you happen to know if there is a definition of the > (expected) contents of a hotspot build - as you can probably tell, I rather > assumed that a bin directory (and indeed bin/java) would be in there. > > If you build hotspot, look what it produces in the dist sub directory > in the build output. > > David Holmes also has a valid point. The bin/java in the imported hotspot > might not even be runnable if we are cross compiling. In that case we also > need to refrain from trying to run it. > > /Erik > > ?TIA & 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 8 May 2014 08:56, Erik Joelsson wrote: > >> Hello Dave, >> >> Adding this information certainly makes sense. While probably not a very >> common usecase, it is currently possible to point "--with-import-hotspot" >> to the dist directory of a Hotspot build. The problem then is that there >> will be no java launcher present to query for version information. Could >> you please add a condition on the existance of >> $with_import_hotspot/bin/java before trying to run it? If it's not there, >> the version will simply be unknown. >> >> The patch looks like it's missing indentation. This might be because of >> formatting in JIRA, but in case it's not, please indent the if statements >> properly with 2 spaces. >> >> /Erik >> ? >> > > From philip.race at oracle.com Thu May 8 16:35:56 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 08 May 2014 09:35:56 -0700 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <532224DF.9070202@oracle.com> References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> <5320DCEB.10205@oracle.com> <532224DF.9070202@oracle.com> Message-ID: <536BB26C.80507@oracle.com> Do we yet have a definitive answer to whether this is a javac bug or something that needs to be fixed in the build ? -phil. On 3/13/14 2:36 PM, Bradford Wetmore wrote: > Phil, > > That looks exactly like my problem. > > http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html > Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9 > using a 32-bit bootdir. > > > Yes, 32 bit it appears, although I didn't supply the boot dir option, > > it chose it all by itself. > > I *BELIEVE* that for the bootdirs discovery (I haven't checked the > code), if a JDK isn't given one with config's --with-boot-jdk, it > defaults to whatever JDK is found in the path. I typically only > install a 32-bit one, as several applets I use require 32-bit only. > > > Who can dig into how much heap is actually needed and see if some new > > bug is requiring more than that ? > > As for how much head is actually needed, I haven't dug into it, but > just doing a simple javac -XmxXXXM Foo.java, I could only get up to > about 1500M. I wasn't able to build on my laptop, but my lab machine > worked just fine, so it's probably close to the border. > > Brad > > > > > > > On 3/12/2014 3:17 PM, Phil Race wrote: >> Yes, 32 bit it appears, although I didn't supply the boot dir option, it >> chose it all by itself. >> Who can dig into how much heap is actually needed and see if some new >> bug is >> requiring more than that ? >> >> -phil. >> >> On 3/12/2014 3:06 PM, Mike Duigou wrote: >>> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last >>> week. The problem in his case was that the 32 bit VM couldn't get a >>> large enough heap. Switching to a 64 bit boot jdk resolved the issue >>> for him. >>> >>> Mike >>> >>> On Mar 12 2014, at 14:45 , Phil Race wrote: >>> >>>> I'm on Windows 7 64 bit and I've quit every app except for my >>>> console windows >>>> yet I still get this error below. >>>> >>>> How can I get past this ? >>>> >>>> -phil. >>>> >>>> ---------- >>>> ## Starting jdk >>>> Compiling 9635 files for BUILD_JDK >>>> >>>> >>>> The system is out of resources. >>>> Consult the following stack trace for details. >>>> java.lang.OutOfMemoryError: Java heap space >>>> at >>>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) >>>> at >>>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja >>>> va:780) >>>> .... >>>> .... >>>> >>>> make[2]: *** >>>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] >>>> >>>> Error 3 >>>> BuildJdk.gmk:64: recipe for target `classes-only' failed >>>> make[1]: *** [classes-only] Error 2 >>>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target >>>> `jdk-only' failed >>>> make: *** [jdk-only] Error 2 >>>> --------------------- >> From mike.duigou at oracle.com Thu May 8 19:13:14 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 8 May 2014 12:13:14 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: <531F05D3.6020008@oracle.com> Message-ID: Ping. Still needing reviewers on this issue. I plan to push this change through the hotspot-rt repo. Mike On May 3 2014, at 20:24 , Mike Duigou wrote: > Hello; > > Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. > > This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ > > Mike > > On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: > >> On 2014-03-11 00:49, Mike Duigou wrote: >>> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>> >>> This version is, hopefully, almost ready to be pushed. >> >> I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. >> >> The top-level build changes looks fine. Thank you Mike for cleaning things up! >> >> /Magnus >> >>> >>> Mike >>> >>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>>> >>>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>>> >>>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>>> >>>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>>> >>>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>>> >>>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>> >>>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>> >>>> Thanks, >>>> >>>> Mike >> > From vladimir.kozlov at oracle.com Thu May 8 19:16:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 May 2014 12:16:43 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: <531F05D3.6020008@oracle.com> Message-ID: <536BD81B.7020709@oracle.com> Hotspot changes look good. Vladimir On 5/3/14 8:24 PM, Mike Duigou wrote: > Hello; > > Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. > > This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ > > Mike > > On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: > >> On 2014-03-11 00:49, Mike Duigou wrote: >>> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>> >>> This version is, hopefully, almost ready to be pushed. >> >> I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. >> >> The top-level build changes looks fine. Thank you Mike for cleaning things up! >> >> /Magnus >> >>> >>> Mike >>> >>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>>> >>>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>>> >>>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>>> >>>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>>> >>>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>>> >>>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>> >>>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>> >>>> Thanks, >>>> >>>> Mike >> > From mike.duigou at oracle.com Fri May 9 02:19:50 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 8 May 2014 19:19:50 -0700 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo Message-ID: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> Hello all; This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. https://bugs.openjdk.java.net/browse/JDK-8042810 http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ Mike From david.holmes at oracle.com Fri May 9 04:07:52 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 May 2014 14:07:52 +1000 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: <531F05D3.6020008@oracle.com> Message-ID: <536C5498.80903@oracle.com> Hi Mike, This looks okay to me, but of course the proof is in the building and testing. David On 4/05/2014 1:24 PM, Mike Duigou wrote: > Hello; > > Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. > > This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ > > Mike > > On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: > >> On 2014-03-11 00:49, Mike Duigou wrote: >>> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>> >>> This version is, hopefully, almost ready to be pushed. >> >> I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. >> >> The top-level build changes looks fine. Thank you Mike for cleaning things up! >> >> /Magnus >> >>> >>> Mike >>> >>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>>> >>>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>>> >>>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>>> >>>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>>> >>>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>>> >>>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>> >>>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>> >>>> Thanks, >>>> >>>> Mike >> > From chris.hegarty at oracle.com Fri May 9 05:35:03 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 May 2014 06:35:03 +0100 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> Message-ID: Looks fine to me Mike. Trivially while you are there (not related to your changes), or i can do it separately, --sequentially now runs with up to two parallel commands. -Chris > On 9 May 2014, at 03:19, Mike Duigou wrote: > > Hello all; > > This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. > > I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. > > https://bugs.openjdk.java.net/browse/JDK-8042810 > http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ > > Mike From mike.duigou at oracle.com Fri May 9 07:25:27 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 9 May 2014 00:25:27 -0700 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> Message-ID: <7926E927-29E6-429E-B441-5544F7F79168@oracle.com> On May 8 2014, at 22:35 , Chris Hegarty wrote: > Looks fine to me Mike. > > Trivially while you are there (not related to your changes), or i can do it separately, --sequentially now runs with up to two parallel commands. Ah sorry, I know why that is. It is due to shell having less-than but no less-than-or-equal-to operator. I can fix this easily and will do so before pushing. It's simply a matter of reducing at_a_time to 0. This will look odd but solve the problem. > > -Chris > >> On 9 May 2014, at 03:19, Mike Duigou wrote: >> >> Hello all; >> >> This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. >> >> I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. >> >> https://bugs.openjdk.java.net/browse/JDK-8042810 >> http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ >> >> Mike From erik.joelsson at oracle.com Fri May 9 07:52:06 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 09 May 2014 09:52:06 +0200 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: <531F05D3.6020008@oracle.com> Message-ID: <536C8926.4070808@oracle.com> Looks good to me. /Erik On 2014-05-04 05:24, Mike Duigou wrote: > Hello; > > Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. > > This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. > > https://bugs.openjdk.java.net/browse/JDK-8032045 > http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ > > Mike > > On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: > >> On 2014-03-11 00:49, Mike Duigou wrote: >>> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>> >>> This version is, hopefully, almost ready to be pushed. >> I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. >> >> The top-level build changes looks fine. Thank you Mike for cleaning things up! >> >> /Magnus >> >>> Mike >>> >>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>>> >>>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>>> >>>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>>> >>>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>>> >>>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>>> >>>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>> >>>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>> >>>> Thanks, >>>> >>>> Mike From erik.joelsson at oracle.com Fri May 9 08:38:02 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 09 May 2014 10:38:02 +0200 Subject: JDK9 build failure on Windows : javac OutOfMemoryError In-Reply-To: <536BB26C.80507@oracle.com> References: <5320D57D.1040708@oracle.com> <0D6C8060-2367-4D44-89C1-923A35804270@oracle.com> <5320DCEB.10205@oracle.com> <532224DF.9070202@oracle.com> <536BB26C.80507@oracle.com> Message-ID: <536C93EA.5050209@oracle.com> I do not know and I don't see what could be done from the build point of view. When we restructure the source for modules, each unit of compilation will be much smaller so the problem will most likely go away. /Erik On 2014-05-08 18:35, Phil Race wrote: > Do we yet have a definitive answer to whether this is a javac bug > or something that needs to be fixed in the build ? > > -phil. > > On 3/13/14 2:36 PM, Bradford Wetmore wrote: >> Phil, >> >> That looks exactly like my problem. >> >> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012089.html >> Subject: Heads Up: OutOfMemoryError when building a 64-bit JDK 9 >> using a 32-bit bootdir. >> >> > Yes, 32 bit it appears, although I didn't supply the boot dir option, >> > it chose it all by itself. >> >> I *BELIEVE* that for the bootdirs discovery (I haven't checked the >> code), if a JDK isn't given one with config's --with-boot-jdk, it >> defaults to whatever JDK is found in the path. I typically only >> install a 32-bit one, as several applets I use require 32-bit only. >> >> > Who can dig into how much heap is actually needed and see if some new >> > bug is requiring more than that ? >> >> As for how much head is actually needed, I haven't dug into it, but >> just doing a simple javac -XmxXXXM Foo.java, I could only get up to >> about 1500M. I wasn't able to build on my laptop, but my lab machine >> worked just fine, so it's probably close to the border. >> >> Brad >> >> >> >> >> >> >> On 3/12/2014 3:17 PM, Phil Race wrote: >>> Yes, 32 bit it appears, although I didn't supply the boot dir >>> option, it >>> chose it all by itself. >>> Who can dig into how much heap is actually needed and see if some new >>> bug is >>> requiring more than that ? >>> >>> -phil. >>> >>> On 3/12/2014 3:06 PM, Mike Duigou wrote: >>>> Is your bootjdk a 32 bit VM? Brad Wetmore had similar issues last >>>> week. The problem in his case was that the 32 bit VM couldn't get a >>>> large enough heap. Switching to a 64 bit boot jdk resolved the issue >>>> for him. >>>> >>>> Mike >>>> >>>> On Mar 12 2014, at 14:45 , Phil Race wrote: >>>> >>>>> I'm on Windows 7 64 bit and I've quit every app except for my >>>>> console windows >>>>> yet I still get this error below. >>>>> >>>>> How can I get past this ? >>>>> >>>>> -phil. >>>>> >>>>> ---------- >>>>> ## Starting jdk >>>>> Compiling 9635 files for BUILD_JDK >>>>> >>>>> >>>>> The system is out of resources. >>>>> Consult the following stack trace for details. >>>>> java.lang.OutOfMemoryError: Java heap space >>>>> at >>>>> com.sun.tools.javac.tree.TreeMaker.Literal(TreeMaker.java:451) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:740) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:660) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1158) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:910) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:881) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:837) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:817) >>>>> at >>>>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.ja >>>>> va:780) >>>>> .... >>>>> .... >>>>> >>>>> make[2]: *** >>>>> [/cygdrive/c/jdks/client/build/windows-x86-normal-serverANDclient-release/jdk/classes/_the.BUILD_JDK_batch] >>>>> >>>>> Error 3 >>>>> BuildJdk.gmk:64: recipe for target `classes-only' failed >>>>> make[1]: *** [classes-only] Error 2 >>>>> /cygdrive/c/jdks/client//make/Main.gmk:116: recipe for target >>>>> `jdk-only' failed >>>>> make: *** [jdk-only] Error 2 >>>>> --------------------- >>> > From pointo1d at gmail.com Fri May 9 08:54:05 2014 From: pointo1d at gmail.com (pointo1d) Date: Fri, 09 May 2014 09:54:05 +0100 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <7926E927-29E6-429E-B441-5544F7F79168@oracle.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> <7926E927-29E6-429E-B441-5544F7F79168@oracle.com> Message-ID: <536C97AD.5060203@gmail.com> Hi Mike , On 09/05/14 08:25, Mike Duigou wrote: > On May 8 2014, at 22:35 , Chris Hegarty wrote: > >> Looks fine to me Mike. >> >> Trivially while you are there (not related to your changes), or i can do it separately, --sequentially now runs with up to two parallel commands. > Ah sorry, I know why that is. It is due to shell having less-than but no less-than-or-equal-to operator. I can fix this easily and will do so before pushing. It's simply a matter of reducing at_a_time to 0. This will look odd but solve the problem. You didn't mean 'test -le' for the less-than-or-equal-to operator, did you ? >> -Chris >> >>> On 9 May 2014, at 03:19, Mike Duigou wrote: >>> >>> Hello all; >>> >>> This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. >>> >>> I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8042810 >>> http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ >>> >>> Mike 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 From pointo1d at gmail.com Fri May 9 10:54:43 2014 From: pointo1d at gmail.com (pointo1d) Date: Fri, 09 May 2014 11:54:43 +0100 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> Message-ID: <536CB3F3.7010308@gmail.com> Hi Mike , On 09/05/14 03:19, Mike Duigou wrote: > Hello all; > > This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. > > I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. Is either your test harness or your test cases available for general consumption in order that I might try them out and thus test and I trust confirm, the fix, on AIX (and indeed z/OS) please ? > https://bugs.openjdk.java.net/browse/JDK-8042810 > http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ > > Mike 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 From pointo1d at gmail.com Fri May 9 12:32:16 2014 From: pointo1d at gmail.com (pointo1d) Date: Fri, 09 May 2014 13:32:16 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536B38C7.70800@oracle.com> References: <536B38C7.70800@oracle.com> Message-ID: <536CCAD0.7040101@gmail.com> Hi all , By way of a heads-up, I deem that the nature and relative size of the change (incorporating the comments from both Erik & David) now requires a webrev, so one has been generated and is awaiting hosting up on openjdk - of which further news as and when available. On the point of which, I note that the contributor guide (http://openjdk.java.net/contribute/) claims that patches may be either in the body of, or attached to, e-mails but as we all know, attachments are removed - is this because they are ZIP files, or are ALL attachments removed be as it may and the guide is wrong in this respect ? 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 From pointo1d at gmail.com Fri May 9 12:49:04 2014 From: pointo1d at gmail.com (pointo1d) Date: Fri, 09 May 2014 13:49:04 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536B38C7.70800@oracle.com> References: <536B38C7.70800@oracle.com> Message-ID: <536CCEC0.7030402@gmail.com> Further to my previous e-mail, pls be advised that the webrev is now up on openjdk at http://cr.openjdk.java.net/~ngmr/8037953/webrev.00. 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 From mikael.vidstedt at oracle.com Fri May 9 21:32:50 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 09 May 2014 14:32:50 -0700 Subject: RFR (XS): 8042804: Support invoking Hotspot tests from top level Message-ID: <536D4982.6020308@oracle.com> All, Can I please get a review or two of the below change, which makes it possible to invoke/run the hotspot tests from the top level test/Makefile too - much like the jdk, langtools etc. tests. The implementation does this by simply delegating to the hotspot/test/Makefile - again, much like the jdk, langtools logic does. * Bug: https://bugs.openjdk.java.net/browse/JDK-8042804 * Webrevs top: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/top/ hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/hotspot/webrev/ Thanks, Mikael From daniel.smith at oracle.com Fri May 9 23:43:15 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Fri, 9 May 2014 17:43:15 -0600 Subject: Langtools test makefile enhancement Message-ID: Hi, I just created an Enhancement, JDK-8042882, requesting some extra control over verbosity in langtools/test/Makefile. I've got a patch that does this that I've been using locally for awhile now. Can I claim the issue and post my patch for review to this list, or is there a different process I should follow? Thanks, Dan From jonathan.gibbons at oracle.com Fri May 9 23:47:12 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 09 May 2014 16:47:12 -0700 Subject: Langtools test makefile enhancement In-Reply-To: References: Message-ID: <536D6900.6030708@oracle.com> You should coordinate with Mike Duigou who has had ideas for aligning langtools/test/Makefile with jdk/test/Makefile. -- Jon On 05/09/2014 04:43 PM, Dan Smith wrote: > Hi, > > I just created an Enhancement, JDK-8042882, requesting some extra control over verbosity in langtools/test/Makefile. > > I've got a patch that does this that I've been using locally for awhile now. Can I claim the issue and post my patch for review to this list, or is there a different process I should follow? > > Thanks, > Dan From david.holmes at oracle.com Mon May 12 07:16:46 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 May 2014 17:16:46 +1000 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536CCAD0.7040101@gmail.com> References: <536B38C7.70800@oracle.com> <536CCAD0.7040101@gmail.com> Message-ID: <5370755E.7000503@oracle.com> On 9/05/2014 10:32 PM, pointo1d wrote: > Hi all , > > By way of a heads-up, I deem that the nature and relative size of the > change (incorporating the comments from both Erik & David) now requires > a webrev, so one has been generated and is awaiting hosting up on > openjdk - of which further news as and when available. > > On the point of which, I note that the contributor guide > (http://openjdk.java.net/contribute/) claims that patches may be either > in the body of, or attached to, e-mails but as we all know, attachments > are removed - is this because they are ZIP files, or are ALL attachments > removed be as it may and the guide is wrong in this respect ? All attachments are no longer removed, but likely zip files still are. If the patch is big enough to need a webrev the webrev should be hosted on cr.openjdk.java.net - attaching a webrev (even if permitted is a pain-in-the-butt for reviewers). David H. ------- > 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 > From david.holmes at oracle.com Mon May 12 07:20:38 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 May 2014 17:20:38 +1000 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <536C5498.80903@oracle.com> References: <531F05D3.6020008@oracle.com> <536C5498.80903@oracle.com> Message-ID: <53707646.9020805@oracle.com> For the Open record, the hotspot fix has an issue because FASTDEBUG_CFLAGS is unused on linux/bsd. David On 9/05/2014 2:07 PM, David Holmes wrote: > Hi Mike, > > This looks okay to me, but of course the proof is in the building and > testing. > > David > > On 4/05/2014 1:24 PM, Mike Duigou wrote: >> Hello; >> >> Finally getting back to this issue I have done some cleanup and >> adjusted the hotspot gcc.make files to use VARIANT rather than >> DEBUG_LEVEL. >> >> This version also add support for the "-fsanitize=undefined" undefined >> behaviour warnings feature when it is available (Clang and GCC 4.9). >> The code to emit the option has been added for Clang but I haven't yet >> added test for the option's availability under Clang so currently it >> will be enabled only for GCC. >> >> https://bugs.openjdk.java.net/browse/JDK-8032045 >> http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ >> >> Mike >> >> On Mar 11 2014, at 05:47 , Magnus Ihse Bursie >> wrote: >> >>> On 2014-03-11 00:49, Mike Duigou wrote: >>>> I have updated the patch to respond to Magnus's feedback and to >>>> accommodate intervening changes to the configure and hotspot make >>>> files. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>>> >>>> This version is, hopefully, almost ready to be pushed. >>> >>> I have only glanced at the hotspot build changes and can't really say >>> anything about them. The hotspot team still owns these; I'm cc:ing >>> them now. >>> >>> The top-level build changes looks fine. Thank you Mike for cleaning >>> things up! >>> >>> /Magnus >>> >>>> >>>> Mike >>>> >>>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> This issue is a followon to JDK-8030350 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced >>>>> the compiler warnings used for compiling native code. The proposed >>>>> changes principally impact the Linux platform. >>>>> >>>>> While 8030350 was focused on compiler warnings which did not impact >>>>> code generation, this changeset will, for some configurations, >>>>> change the native code generated and likely change performance. >>>>> These proposed option changes prevent specific types of relocation >>>>> table, stack and heap memory corruption in native code. Preventing >>>>> these types of memory corruption may be useful for finding certain >>>>> kinds of bugs though and do provide some minimal additional >>>>> protections against malicious attacks. They aren't, by any means, a >>>>> substitute for following appropriate secure coding guidelines. >>>>> >>>>> The rationale behind the implementation is as follows. For release >>>>> builds during the initial phase of JDK 9 I would like to enable >>>>> only compile time checks. This ends up being similar to the >>>>> warnings in JDK-8030350. These options have no runtime impact on >>>>> footprint or performance and very minimal additional compile time >>>>> cost while providing value. **Release builds are not expected to >>>>> see any performance or footprint change as a result of this >>>>> changeset** >>>>> >>>>> For fast debug builds we can enable linker protections (relro) and >>>>> static compile time bounds checks (FORTIFY_SOURCE=1). >>>>> FORTIFY_SOURCE=1 might be moved to the production builds as well >>>>> because it has no runtime cost or executable size cost. >>>>> >>>>> For slow debug builds we can enable full linker protection (at a >>>>> potential cost in startup time), runtime bounds checks and stack >>>>> protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely >>>>> enable -fprotect-stack-strong when available in GCC 4.9 >>>>> >>>>> The basis for enabling the additional protections in debug builds >>>>> is that it will help us find bugs in our native code and we aren't >>>>> as concerned in debug builds with footprint and performance. Since >>>>> many developers already do their personal builds in fastdebug or >>>>> slowdebug mode for testing this will provide good opportunity to >>>>> shake out any problems with the options while not impacting release >>>>> builds. Should we find that any of the options provide significant >>>>> value for their cost we can move them to fastdebug or release. If >>>>> any of the options prove too costly they can be demoted or removed >>>>> entirely. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>>> >>>>> Additional to enabling the various compiler options I attempted to >>>>> rationalize some of the skew between the various >>>>> hotspot/make/{platform}/makefiles/gcc.make files while avoiding >>>>> changing existing behaviour. I have also introduced the new -Og >>>>> "optimize for debugging" option and there are now an explicit >>>>> C{XX}_O_FLAG_DEBUG definitions to complement the >>>>> C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>>> >>>>> Thanks, >>>>> >>>>> Mike >>> >> From staffan.larsen at oracle.com Mon May 12 07:30:19 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 12 May 2014 09:30:19 +0200 Subject: RFR (XS): 8042804: Support invoking Hotspot tests from top level In-Reply-To: <536D4982.6020308@oracle.com> References: <536D4982.6020308@oracle.com> Message-ID: <747CFF9F-F5A2-4E88-9321-1E9E090001CD@oracle.com> Looks good! Thanks, /Staffan On 9 maj 2014, at 23:32, Mikael Vidstedt wrote: > > All, > > Can I please get a review or two of the below change, which makes it possible to invoke/run the hotspot tests from the top level test/Makefile too - much like the jdk, langtools etc. tests. The implementation does this by simply delegating to the hotspot/test/Makefile - again, much like the jdk, langtools logic does. > > * Bug: > > https://bugs.openjdk.java.net/browse/JDK-8042804 > > * Webrevs > > top: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/top/ > hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/hotspot/webrev/ > > Thanks, > Mikael > From erik.joelsson at oracle.com Mon May 12 08:35:47 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 May 2014 10:35:47 +0200 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536CCEC0.7030402@gmail.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> Message-ID: <537087E3.2070505@oracle.com> Hello Dave, This looks better. However, the test for cross compilation is bit too restrictive. We have a variable called COMPILE_TYPE which can have the values "native", "reduced" and "cross". Reduced means that we compile for 32bit on an architecture that normally supports 64bit, and achieved with the --with-target-bits=32 flag. With the current test the hotspot version is not printed when a "reduced" compile is configured. I would suggest testing for COMPILE_TYPE != cross. /Erik On 2014-05-09 14:49, pointo1d wrote: > Further to my previous e-mail, pls be advised that the webrev is now > up on openjdk at http://cr.openjdk.java.net/~ngmr/8037953/webrev.00. > > Rgds , > From erik.joelsson at oracle.com Mon May 12 08:38:05 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 May 2014 10:38:05 +0200 Subject: RFR (XS): 8042804: Support invoking Hotspot tests from top level In-Reply-To: <536D4982.6020308@oracle.com> References: <536D4982.6020308@oracle.com> Message-ID: <5370886D.6000802@oracle.com> Looks good to me. /Erik On 2014-05-09 23:32, Mikael Vidstedt wrote: > > All, > > Can I please get a review or two of the below change, which makes it > possible to invoke/run the hotspot tests from the top level > test/Makefile too - much like the jdk, langtools etc. tests. The > implementation does this by simply delegating to the > hotspot/test/Makefile - again, much like the jdk, langtools logic does. > > * Bug: > > https://bugs.openjdk.java.net/browse/JDK-8042804 > > * Webrevs > > top: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/top/ > hotspot: > http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/hotspot/webrev/ > > Thanks, > Mikael > From pointo1d at gmail.com Mon May 12 09:40:49 2014 From: pointo1d at gmail.com (pointo1d) Date: Mon, 12 May 2014 10:40:49 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <537087E3.2070505@oracle.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> <537087E3.2070505@oracle.com> Message-ID: <53709721.7020804@gmail.com> Hi Erik , On 12/05/14 09:35, Erik Joelsson wrote: > Hello Dave, > > This looks better. However, the test for cross compilation is bit too > restrictive. We have a variable called COMPILE_TYPE which can have the > values "native", "reduced" and "cross". Reduced means that we compile > for 32bit on an architecture that normally supports 64bit, and > achieved with the --with-target-bits=32 flag. With the current test > the hotspot version is not printed when a "reduced" compile is > configured. I would suggest testing for COMPILE_TYPE != cross. > > /Erik Thanx for that, I did play with a test of "x$COMPILE_TYPE" = "xnative", but obviously the semantics of the values weren't quite as clear as I thought. > > On 2014-05-09 14:49, pointo1d wrote: >> Further to my previous e-mail, pls be advised that the webrev is now >> up on openjdk at http://cr.openjdk.java.net/~ngmr/8037953/webrev.00. >> >> Rgds , >> > Thanx again , -- ?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 From david.holmes at oracle.com Mon May 12 09:50:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 May 2014 19:50:42 +1000 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <53709721.7020804@gmail.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> <537087E3.2070505@oracle.com> <53709721.7020804@gmail.com> Message-ID: <53709972.5040705@oracle.com> Also this appears to need the x to be quoted "x" + if test "x$with_import_hotspot" != x; then at least that is the normal pattern (it may not be strictly necessary). David H. On 12/05/2014 7:40 PM, pointo1d wrote: > Hi Erik , > > On 12/05/14 09:35, Erik Joelsson wrote: >> Hello Dave, >> >> This looks better. However, the test for cross compilation is bit too >> restrictive. We have a variable called COMPILE_TYPE which can have the >> values "native", "reduced" and "cross". Reduced means that we compile >> for 32bit on an architecture that normally supports 64bit, and >> achieved with the --with-target-bits=32 flag. With the current test >> the hotspot version is not printed when a "reduced" compile is >> configured. I would suggest testing for COMPILE_TYPE != cross. >> >> /Erik > > Thanx for that, I did play with a test of "x$COMPILE_TYPE" = "xnative", > but obviously the semantics of the values weren't quite as clear as I > thought. > >> >> On 2014-05-09 14:49, pointo1d wrote: >>> Further to my previous e-mail, pls be advised that the webrev is now >>> up on openjdk at http://cr.openjdk.java.net/~ngmr/8037953/webrev.00. >>> >>> Rgds , >>> >> > > Thanx again , > From pointo1d at gmail.com Mon May 12 10:13:53 2014 From: pointo1d at gmail.com (pointo1d) Date: Mon, 12 May 2014 11:13:53 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <536CCEC0.7030402@gmail.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> Message-ID: <53709EE1.5030904@gmail.com> Thanx all , Pls be advised that the comments have been incorporated and the webrev updated - at http://cr.openjdk.java.net/~ngmr/8037953/webrev.01. 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 From pointo1d at gmail.com Mon May 12 10:19:59 2014 From: pointo1d at gmail.com (pointo1d) Date: Mon, 12 May 2014 11:19:59 +0100 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <53709972.5040705@oracle.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> <537087E3.2070505@oracle.com> <53709721.7020804@gmail.com> <53709972.5040705@oracle.com> Message-ID: <5370A04F.9030109@gmail.com> On 12/05/14 10:50, David Holmes wrote: > Also this appears to need the x to be quoted "x" > > + if test "x$with_import_hotspot" != x; then > > at least that is the normal pattern (it may not be strictly necessary). Hmm, I was following, or attempting to follow, the 'convention' as illustrated elsewhere in the file e.g. the previous test, where the single char 'x' is not quoted. I have to say that the quoting of string constants not containing white space is a little OTT and as you suggest, not at all necessary - even in the most basic of Bourne shells. 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 From erik.joelsson at oracle.com Mon May 12 11:44:18 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 May 2014 13:44:18 +0200 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <53709EE1.5030904@gmail.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> <53709EE1.5030904@gmail.com> Message-ID: <5370B412.3050105@oracle.com> This looks good to me. /Erik On 2014-05-12 12:13, pointo1d wrote: > Thanx all , > > Pls be advised that the comments have been incorporated and the webrev > updated - at http://cr.openjdk.java.net/~ngmr/8037953/webrev.01. > > 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 From pointo1d at gmail.com Mon May 12 12:06:44 2014 From: pointo1d at gmail.com (pointo1d) Date: Mon, 12 May 2014 13:06:44 +0100 Subject: JDK-8028446: Shell options are not passed to configure script from its wrapper Message-ID: <5370B954.7050201@gmail.com> Hi , Further to previous e-mails on the above subject, an update to the simple patch incorporates Magnus' clarification comment (or a variant thereof) ... diff -r 9263073b1d95 configure --- a/configure Fri May 09 16:24:59 2014 +0100 +++ b/configure Mon May 12 13:03:17 2014 +0100 @@ -26,4 +26,6 @@ # make sure that is called using bash. this_script_dir=`dirname $0` + +# Now invoke the sub-script - using propagated shell options, if any bash ${-:+-$-} $this_script_dir/common/autoconf/configure "$@" 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 From mikael.vidstedt at oracle.com Mon May 12 13:22:19 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 12 May 2014 06:22:19 -0700 Subject: RFR (XS): 8042804: Support invoking Hotspot tests from top level In-Reply-To: <5370886D.6000802@oracle.com> References: <536D4982.6020308@oracle.com> <5370886D.6000802@oracle.com> Message-ID: <5370CB0B.7040404@oracle.com> Staffan, Erik - thanks for the reviews! Cheers, Mikael On 2014-05-12 01:38, Erik Joelsson wrote: > Looks good to me. > > /Erik > > On 2014-05-09 23:32, Mikael Vidstedt wrote: >> >> All, >> >> Can I please get a review or two of the below change, which makes it >> possible to invoke/run the hotspot tests from the top level >> test/Makefile too - much like the jdk, langtools etc. tests. The >> implementation does this by simply delegating to the >> hotspot/test/Makefile - again, much like the jdk, langtools logic does. >> >> * Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8042804 >> >> * Webrevs >> >> top: http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/top/ >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8042804/webrev.00/hotspot/webrev/ >> >> Thanks, >> Mikael >> > From daniel.smith at oracle.com Mon May 12 18:16:05 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 12 May 2014 12:16:05 -0600 Subject: RFR: JDK-8042882: Support verbosity options in langtools testing Message-ID: A patch to enhance langtools/test/Makefile is inline, below. This addresses JDK-8042882, adding a variable to control verbosity. I've also slipped in a fix for JDK-8032441, eliminating the use of the MaxPermSize JVM option (deprecated in 8, gone in 9) when running JCK tests. ?Dan # HG changeset patch # Parent e5d0d7510671bc6725cb0f231553697bf6ca76b6 diff -r e5d0d7510671 test/Makefile --- a/test/Makefile Fri May 09 14:56:59 2014 -0600 +++ b/test/Makefile Mon May 12 12:05:29 2014 -0600 @@ -186,6 +186,12 @@ JTREG_OPTIONS += -timeoutFactor:$(JTREG_TIMEOUT_FACTOR) endif +# Default verbosity setting for jtreg +JTREG_VERBOSE = fail,error,nopass + +# Default verbosity setting for jck +JCK_VERBOSE = non-pass + # Assertions: some tests show failures when assertions are enabled. # Since javac is typically loaded via the bootclassloader (either via TESTJAVA # or TESTBOOTCLASSPATH), you may need -esa to enable assertions in javac. @@ -256,6 +262,8 @@ # Version of java used to run jtreg. Should normally be the same as TESTJAVA # TESTJAVA # Version of java to be tested. +# JTREG_VERBOSE +# Verbosity setting for jtreg # JTREG_OPTIONS # Additional options for jtreg # JTREG_TESTDIRS @@ -273,7 +281,7 @@ JT_JAVA=$(JT_JAVA) $(JTREG) \ -J-Xmx512m \ -vmoption:-Xmx768m \ - -a -ignore:quiet -v:fail,error,nopass \ + -a -ignore:quiet $(if $(JTREG_VERBOSE),-v:$(JTREG_VERBOSE)) \ -r:$(JTREG_OUTPUT_DIR)/JTreport \ -w:$(JTREG_OUTPUT_DIR)/JTwork \ -jdk:$(TESTJAVA) \ @@ -312,6 +320,8 @@ # Default is JDK 7 # TESTJAVA # Version of java to be tested. +# JCK_VERBOSE +# Verbosity setting for jtjck # JCK_COMPILER_OPTIONS # Additional options for JCK-compiler # JCK_COMPILER_TESTDIRS @@ -325,9 +335,9 @@ @rm -f -r $(JCK_COMPILER_OUTPUT_DIR)/work $(JCK_COMPILER_OUTPUT_DIR)/report \ $(JCK_COMPILER_OUTPUT_DIR)/diff.html $(JCK_COMPILER_OUTPUT_DIR)/status.txt @mkdir -p $(JCK_COMPILER_OUTPUT_DIR) - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ + $(JT_JAVA)/bin/java -Xmx512m \ -jar $(JCK_HOME)/JCK-compiler-8/lib/jtjck.jar \ - -v:non-pass \ + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ -r:$(JCK_COMPILER_OUTPUT_DIR)/report \ -w:$(JCK_COMPILER_OUTPUT_DIR)/work \ -jdk:$(TESTJAVA) \ @@ -361,6 +371,8 @@ # Version of java used to run JCK. Should normally be the same as TESTJAVA # TESTJAVA # Version of java to be tested. +# JCK_VERBOSE +# Verbosity setting for jtjck # JCK_RUNTIME_OPTIONS # Additional options for JCK-runtime # JCK_RUNTIME_TESTDIRS @@ -374,9 +386,9 @@ @rm -f -r $(JCK_RUNTIME_OUTPUT_DIR)/work $(JCK_RUNTIME_OUTPUT_DIR)/report \ $(JCK_RUNTIME_OUTPUT_DIR)/diff.html $(JCK_RUNTIME_OUTPUT_DIR)/status.txt @mkdir -p $(JCK_RUNTIME_OUTPUT_DIR) - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ + $(JT_JAVA)/bin/java -Xmx512m \ -jar $(JCK_HOME)/JCK-runtime-8/lib/jtjck.jar \ - -v:non-pass \ + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ -r:$(JCK_RUNTIME_OUTPUT_DIR)/report \ -w:$(JCK_RUNTIME_OUTPUT_DIR)/work \ -jdk:$(TESTJAVA) \ From mike.duigou at oracle.com Mon May 12 18:36:08 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 12 May 2014 11:36:08 -0700 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <536CB3F3.7010308@gmail.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> <536CB3F3.7010308@gmail.com> Message-ID: <3A1D6C6A-76DA-4641-925C-A8E405CED69A@oracle.com> On May 9 2014, at 03:54 , pointo1d wrote: > Hi Mike , > > On 09/05/14 03:19, Mike Duigou wrote: >> Hello all; >> >> This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. >> >> I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. > > Is either your test harness or your test cases available for general consumption in order that I might try them out and thus test and I trust confirm, the fix, on AIX (and indeed z/OS) please ? I have neither a formal test harness or test suite. I have been doing all testing manually across all platforms. And this issue demonstrates that there have been gaps in the methodology and coverage. If you have have patches for either of those platforms I would be happy to incorporate them! (Most likely is lack of proper fifo support based upon shell version). I can outline what I do test though. I test on the following: Ubuntu linux 13.10 x64 with default bash and dash, ash Cygwin ("recent update") x64 with default bash MacOS X Mavericks x64 with macports bash (4.3) and when I remember default bash Solaris 11.1 with default bash and ksh93 (/bin/sh is /bin/ksk93) and following this issue I will be also adding testing with Solaris 10u10 or later using it's default bash and ksh93 I usually do development on whichever platform is exhibiting problems. :-) The extra coverage on linux is not because I expect that those shells will be used but because it is convenient and quick to test several likely shells there. For test commands I use a mix of local and remote commands: status summary qpop -a update update -C incoming outgoing pull -u clone serve (which I then test from another instance) I try at least one local and one remote command with the -s option. I run my in a test forest where I can delete sub-repos with impunity. For some testing I had to hack the script to disable fifos. I have improved upon this in the most recent revision by adding support for overriding defaults via environment variables. (see separate notice for webrev update) Mike > >> https://bugs.openjdk.java.net/browse/JDK-8042810 >> http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ >> >> Mike > > 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 > From mike.duigou at oracle.com Mon May 12 21:33:45 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 12 May 2014 14:33:45 -0700 Subject: RFR: JDK-8042882: Support verbosity options in langtools testing In-Reply-To: References: Message-ID: <5E8F9C91-D94D-45DF-B5B0-7C60381B6618@oracle.com> Looks good to me. A very useful addition that I plan to port to the jdk repo. Mike On May 12 2014, at 11:16 , Dan Smith wrote: > A patch to enhance langtools/test/Makefile is inline, below. > > This addresses JDK-8042882, adding a variable to control verbosity. I've also slipped in a fix for JDK-8032441, eliminating the use of the MaxPermSize JVM option (deprecated in 8, gone in 9) when running JCK tests. > > ?Dan > > # HG changeset patch > # Parent e5d0d7510671bc6725cb0f231553697bf6ca76b6 > > diff -r e5d0d7510671 test/Makefile > --- a/test/Makefile Fri May 09 14:56:59 2014 -0600 > +++ b/test/Makefile Mon May 12 12:05:29 2014 -0600 > @@ -186,6 +186,12 @@ > JTREG_OPTIONS += -timeoutFactor:$(JTREG_TIMEOUT_FACTOR) > endif > > +# Default verbosity setting for jtreg > +JTREG_VERBOSE = fail,error,nopass > + > +# Default verbosity setting for jck > +JCK_VERBOSE = non-pass > + > # Assertions: some tests show failures when assertions are enabled. > # Since javac is typically loaded via the bootclassloader (either via TESTJAVA > # or TESTBOOTCLASSPATH), you may need -esa to enable assertions in javac. > @@ -256,6 +262,8 @@ > # Version of java used to run jtreg. Should normally be the same as TESTJAVA > # TESTJAVA > # Version of java to be tested. > +# JTREG_VERBOSE > +# Verbosity setting for jtreg > # JTREG_OPTIONS > # Additional options for jtreg > # JTREG_TESTDIRS > @@ -273,7 +281,7 @@ > JT_JAVA=$(JT_JAVA) $(JTREG) \ > -J-Xmx512m \ > -vmoption:-Xmx768m \ > - -a -ignore:quiet -v:fail,error,nopass \ > + -a -ignore:quiet $(if $(JTREG_VERBOSE),-v:$(JTREG_VERBOSE)) \ > -r:$(JTREG_OUTPUT_DIR)/JTreport \ > -w:$(JTREG_OUTPUT_DIR)/JTwork \ > -jdk:$(TESTJAVA) \ > @@ -312,6 +320,8 @@ > # Default is JDK 7 > # TESTJAVA > # Version of java to be tested. > +# JCK_VERBOSE > +# Verbosity setting for jtjck > # JCK_COMPILER_OPTIONS > # Additional options for JCK-compiler > # JCK_COMPILER_TESTDIRS > @@ -325,9 +335,9 @@ > @rm -f -r $(JCK_COMPILER_OUTPUT_DIR)/work $(JCK_COMPILER_OUTPUT_DIR)/report \ > $(JCK_COMPILER_OUTPUT_DIR)/diff.html $(JCK_COMPILER_OUTPUT_DIR)/status.txt > @mkdir -p $(JCK_COMPILER_OUTPUT_DIR) > - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ > + $(JT_JAVA)/bin/java -Xmx512m \ > -jar $(JCK_HOME)/JCK-compiler-8/lib/jtjck.jar \ > - -v:non-pass \ > + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ > -r:$(JCK_COMPILER_OUTPUT_DIR)/report \ > -w:$(JCK_COMPILER_OUTPUT_DIR)/work \ > -jdk:$(TESTJAVA) \ > @@ -361,6 +371,8 @@ > # Version of java used to run JCK. Should normally be the same as TESTJAVA > # TESTJAVA > # Version of java to be tested. > +# JCK_VERBOSE > +# Verbosity setting for jtjck > # JCK_RUNTIME_OPTIONS > # Additional options for JCK-runtime > # JCK_RUNTIME_TESTDIRS > @@ -374,9 +386,9 @@ > @rm -f -r $(JCK_RUNTIME_OUTPUT_DIR)/work $(JCK_RUNTIME_OUTPUT_DIR)/report \ > $(JCK_RUNTIME_OUTPUT_DIR)/diff.html $(JCK_RUNTIME_OUTPUT_DIR)/status.txt > @mkdir -p $(JCK_RUNTIME_OUTPUT_DIR) > - $(JT_JAVA)/bin/java -XX:MaxPermSize=256m -Xmx512m \ > + $(JT_JAVA)/bin/java -Xmx512m \ > -jar $(JCK_HOME)/JCK-runtime-8/lib/jtjck.jar \ > - -v:non-pass \ > + $(if $(JCK_VERBOSE),-v:$(JCK_VERBOSE)) \ > -r:$(JCK_RUNTIME_OUTPUT_DIR)/report \ > -w:$(JCK_RUNTIME_OUTPUT_DIR)/work \ > -jdk:$(TESTJAVA) \ > From sean.coffey at oracle.com Mon May 12 22:22:56 2014 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 12 May 2014 23:22:56 +0100 Subject: RFR : 8042932: Bump up the -source version for JDK 9 builds Message-ID: <537149C0.1010003@oracle.com> While adding some lambda code to a CORBA class, I got a build time error indicating that the build was running with -source 7. Given that JDK 8 is now the official bootstrap JDK for JDK 9 building, I think we can bump the -source and -target properties up to 8 (from 7) bug ID : https://bugs.openjdk.java.net/browse/JDK-8042932 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/ Thanks to Erik for identifying the offending file. regards, Sean. From mike.duigou at oracle.com Mon May 12 23:27:05 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 12 May 2014 16:27:05 -0700 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <536C97AD.5060203@gmail.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> <7926E927-29E6-429E-B441-5544F7F79168@oracle.com> <536C97AD.5060203@gmail.com> Message-ID: <96E089C3-422E-430D-A7FA-63EFE54AE5DC@oracle.com> On May 9 2014, at 01:54 , pointo1d wrote: > Hi Mike , > > On 09/05/14 08:25, Mike Duigou wrote: >> On May 8 2014, at 22:35 , Chris Hegarty wrote: >> >>> Looks fine to me Mike. >>> >>> Trivially while you are there (not related to your changes), or i can do it separately, --sequentially now runs with up to two parallel commands. >> Ah sorry, I know why that is. It is due to shell having less-than but no less-than-or-equal-to operator. I can fix this easily and will do so before pushing. It's simply a matter of reducing at_a_time to 0. This will look odd but solve the problem. > > You didn't mean 'test -le' for the less-than-or-equal-to operator, did you ? I must have been looking at a strange manual (possibly for not quite the right shell) that didn't include -le in the expression capability. I've since checked and now use -le which makes some expressions more natural! Mike > >>> -Chris >>> >>>> On 9 May 2014, at 03:19, Mike Duigou wrote: >>>> >>>> Hello all; >>>> >>>> This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. >>>> >>>> I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8042810 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ >>>> >>>> Mike > > 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 > From mike.duigou at oracle.com Mon May 12 23:53:40 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 12 May 2014 16:53:40 -0700 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> Message-ID: <0CF0AEFB-56CA-42DF-9554-EC29C4E9A8C1@oracle.com> Hello all; I have updated the webrev after additional testing and cleanup. I found a couple of additional minor problems and added a feature that had been requested. Some of the default behaviour can now be controlled using environment variables. It had been pointed out that being able to run commands as HGFOREST_SEQUENTIAL=true sh get_source.sh would have provided a good work around on broken platforms. I ended up adding a lot of source comments since testing took a while. Maybe someone will find the environment variables useful. I also cleaned up a number of "buglets" and bashisms such as referencing undefined variables, previously failing to report result code of root repo and use of $() in "serve" command. http://cr.openjdk.java.net/~mduigou/JDK-8042810/1/webrev/ Mike On May 8 2014, at 19:19 , Mike Duigou wrote: > Hello all; > > This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. > > I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. > > https://bugs.openjdk.java.net/browse/JDK-8042810 > http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ > > Mike From ioi.lam at oracle.com Tue May 13 03:00:41 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 12 May 2014 20:00:41 -0700 Subject: How to disable demos Message-ID: <53718AD9.60309@oracle.com> I tried the NO_DEMOS flag as in https://bugs.openjdk.java.net/browse/JDK-7143162 "Allow disabling of jdk demos and samples build", but this seems to be in "old build" only, and doesn't affect the new build system. Is there an equivalent for the new build? Thanks - Ioi From chris.hegarty at oracle.com Tue May 13 05:43:46 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 13 May 2014 06:43:46 +0100 Subject: RFR : 8042932: Bump up the -source version for JDK 9 builds In-Reply-To: <537149C0.1010003@oracle.com> References: <537149C0.1010003@oracle.com> Message-ID: <7ADCC872-910A-46F2-BF26-014D0989467C@oracle.com> Looks good to me Sean. -Chris. P.S. don?t forget to push the closed version of gen-conf too. On 12 May 2014, at 23:22, Se?n Coffey wrote: > While adding some lambda code to a CORBA class, I got a build time error indicating that the build was running with -source 7. > > Given that JDK 8 is now the official bootstrap JDK for JDK 9 building, I think we can bump the -source and -target properties up to 8 (from 7) > > bug ID : https://bugs.openjdk.java.net/browse/JDK-8042932 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/ > > Thanks to Erik for identifying the offending file. > > regards, > Sean. From tomas.hurka at googlemail.com Tue May 13 07:01:57 2014 From: tomas.hurka at googlemail.com (Tomas Hurka) Date: Tue, 13 May 2014 09:01:57 +0200 Subject: RFR : 8042932: Bump up the -source version for JDK 9 builds In-Reply-To: <537149C0.1010003@oracle.com> References: <537149C0.1010003@oracle.com> Message-ID: <96BD2EF3-98FB-4E01-A671-9B482E017219@googlemail.com> Hi Sean, I guess that the ?jdk7? text in following comment: # When compiling code to be executed by the Boot JDK, force jdk7 compatibility. should be changed to jdk8. It is on the line before ?BOOT_JDK_SOURCETARGET? change. On 13 May 2014, at 00:22, Se?n Coffey wrote: > While adding some lambda code to a CORBA class, I got a build time error indicating that the build was running with -source 7. > > Given that JDK 8 is now the official bootstrap JDK for JDK 9 building, I think we can bump the -source and -target properties up to 8 (from 7) > > bug ID : https://bugs.openjdk.java.net/browse/JDK-8042932 > webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/ > > Thanks to Erik for identifying the offending file. Bye, -- Tomas Hurka NetBeans Profiler http://profiler.netbeans.org VisualVM http://visualvm.java.net Software Developer Oracle, Praha Czech Republic From erik.joelsson at oracle.com Tue May 13 07:52:56 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 May 2014 09:52:56 +0200 Subject: How to disable demos In-Reply-To: <53718AD9.60309@oracle.com> References: <53718AD9.60309@oracle.com> Message-ID: <5371CF58.2080101@oracle.com> Hello, No, not really. If you do "make jdk" (or just "make" which is the same), demos aren't built. If you do "make images" or "make demos", the demos are built. What is your usecase? If you don't need images, then you are already skipping demos. If you need images, then demos will be built the first time. Building the demos is quite fast these days so we figured it would be better to reduce the complexity of handling builds with or without demos. /Erik On 2014-05-13 05:00, Ioi Lam wrote: > I tried the NO_DEMOS flag as in > https://bugs.openjdk.java.net/browse/JDK-7143162 "Allow disabling of > jdk demos and samples build", but this seems to be in "old build" > only, and doesn't affect the new build system. > > Is there an equivalent for the new build? > > Thanks > > - Ioi From david.holmes at oracle.com Tue May 13 07:53:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 May 2014 17:53:55 +1000 Subject: JDK-8037953 configure usability: Should provide better details on imported hotspot In-Reply-To: <5370A04F.9030109@gmail.com> References: <536B38C7.70800@oracle.com> <536CCEC0.7030402@gmail.com> <537087E3.2070505@oracle.com> <53709721.7020804@gmail.com> <53709972.5040705@oracle.com> <5370A04F.9030109@gmail.com> Message-ID: <5371CF93.4020602@oracle.com> On 12/05/2014 8:19 PM, pointo1d wrote: > > On 12/05/14 10:50, David Holmes wrote: >> Also this appears to need the x to be quoted "x" >> >> + if test "x$with_import_hotspot" != x; then >> >> at least that is the normal pattern (it may not be strictly necessary). > > Hmm, I was following, or attempting to follow, the 'convention' as > illustrated elsewhere in the file e.g. the previous test, where the > single char 'x' is not quoted. I have to say that the quoting of string > constants not containing white space is a little OTT and as you suggest, > not at all necessary - even in the most basic of Bourne shells. Sorry, I had it in my head that the normal pattern was to always quote and the test immediately preceding the change seemed to confirm my thinking if test "x$OPENJDK_BUILD_OS" = "xwindows"; then but as you say this is not necessary and indeed not the common pattern. David > > > Rgds , > From erik.joelsson at oracle.com Tue May 13 07:55:40 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 May 2014 09:55:40 +0200 Subject: RFR : 8042932: Bump up the -source version for JDK 9 builds In-Reply-To: <96BD2EF3-98FB-4E01-A671-9B482E017219@googlemail.com> References: <537149C0.1010003@oracle.com> <96BD2EF3-98FB-4E01-A671-9B482E017219@googlemail.com> Message-ID: <5371CFFC.8090300@oracle.com> Hello Se?n, I agree with Tomas, please fix the comment too. Also don't forget to also push the closed generated-configure using the same bugid. /Erik On 2014-05-13 09:01, Tomas Hurka wrote: > Hi Sean, > I guess that the ?jdk7? text in following comment: > > # When compiling code to be executed by the Boot JDK, force jdk7 compatibility. > > should be changed to jdk8. It is on the line before ?BOOT_JDK_SOURCETARGET? change. > > > On 13 May 2014, at 00:22, Se?n Coffey wrote: > >> While adding some lambda code to a CORBA class, I got a build time error indicating that the build was running with -source 7. >> >> Given that JDK 8 is now the official bootstrap JDK for JDK 9 building, I think we can bump the -source and -target properties up to 8 (from 7) >> >> bug ID : https://bugs.openjdk.java.net/browse/JDK-8042932 >> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/ >> >> Thanks to Erik for identifying the offending file. > Bye, > -- > Tomas Hurka > NetBeans Profiler http://profiler.netbeans.org > VisualVM http://visualvm.java.net > Software Developer > Oracle, Praha Czech Republic > > > From sean.coffey at oracle.com Tue May 13 08:10:48 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 13 May 2014 09:10:48 +0100 Subject: RFR : 8042932: Bump up the -source version for JDK 9 builds In-Reply-To: <5371CFFC.8090300@oracle.com> References: <537149C0.1010003@oracle.com> <96BD2EF3-98FB-4E01-A671-9B482E017219@googlemail.com> <5371CFFC.8090300@oracle.com> Message-ID: <5371D388.4000202@oracle.com> Thanks all - will make that change and push. regards, Sean. On 13/05/2014 08:55, Erik Joelsson wrote: > Hello Se?n, > > I agree with Tomas, please fix the comment too. Also don't forget to > also push the closed generated-configure using the same bugid. > > /Erik > > On 2014-05-13 09:01, Tomas Hurka wrote: >> Hi Sean, >> I guess that the ?jdk7? text in following comment: >> >> # When compiling code to be executed by the Boot JDK, force jdk7 >> compatibility. >> >> should be changed to jdk8. It is on the line before >> ?BOOT_JDK_SOURCETARGET? change. >> >> >> On 13 May 2014, at 00:22, Se?n Coffey wrote: >> >>> While adding some lambda code to a CORBA class, I got a build time >>> error indicating that the build was running with -source 7. >>> >>> Given that JDK 8 is now the official bootstrap JDK for JDK 9 >>> building, I think we can bump the -source and -target properties up >>> to 8 (from 7) >>> >>> bug ID : https://bugs.openjdk.java.net/browse/JDK-8042932 >>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042932/webrev/ >>> >>> Thanks to Erik for identifying the offending file. >> Bye, >> -- >> Tomas Hurka >> NetBeans Profiler http://profiler.netbeans.org >> VisualVM http://visualvm.java.net >> Software Developer >> Oracle, Praha Czech Republic >> >> >> > From erik.joelsson at oracle.com Tue May 13 08:14:12 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 13 May 2014 10:14:12 +0200 Subject: RFR: 8042810: (s) hgforest: some shells run read in sub-shell and can't use fifo In-Reply-To: <0CF0AEFB-56CA-42DF-9554-EC29C4E9A8C1@oracle.com> References: <00D5ECE9-4A62-4356-9513-396D4437E02D@oracle.com> <0CF0AEFB-56CA-42DF-9554-EC29C4E9A8C1@oracle.com> Message-ID: <5371D454.5080108@oracle.com> Looks good to me Mike. Nice work! /Erik On 2014-05-13 01:53, Mike Duigou wrote: > Hello all; > > I have updated the webrev after additional testing and cleanup. I found a couple of additional minor problems and added a feature that had been requested. Some of the default behaviour can now be controlled using environment variables. It had been pointed out that being able to run commands as HGFOREST_SEQUENTIAL=true sh get_source.sh would have provided a good work around on broken platforms. I ended up adding a lot of source comments since testing took a while. Maybe someone will find the environment variables useful. > > I also cleaned up a number of "buglets" and bashisms such as referencing undefined variables, previously failing to report result code of root repo and use of $() in "serve" command. > > http://cr.openjdk.java.net/~mduigou/JDK-8042810/1/webrev/ > > Mike > > On May 8 2014, at 19:19 , Mike Duigou wrote: > >> Hello all; >> >> This issue is a follow-on bug fix to JDK-8041151 (Improve hgforest.sh concurrency). That changeset introduced use of fifos for monitoring sub-shell completion and included an alternative implementation for configurations which did not properly support fifos. This changeset detects another unsupported configuration, older shells which run the "read" command using a sub-shell. >> >> I've tested the change on Solaris 10u11, Solaris 11u1, Ubuntu Linux 13.10 x64, MacOS 10.9. Of these only the Bash 3.2 shell on Solaris 10u11 does not support FIFOs. I have not tested this specific change on Cygwin as FIFOs were already disabled on Cygwin. >> >> https://bugs.openjdk.java.net/browse/JDK-8042810 >> http://cr.openjdk.java.net/~mduigou/JDK-8042810/0/webrev/ >> >> Mike From erik.joelsson at oracle.com Wed May 14 12:32:44 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 May 2014 14:32:44 +0200 Subject: RFR: JDK-8043127: Convert JPRT_ARCHIVE_BUNDLE to unix style paths Message-ID: <5373626C.9000101@oracle.com> Hello, Please review this minor fix for jdk9. The input variables JPRT_ARCHIVE_BUNDLE and JPRT_ARCHIVE_INSTALL_BUNDLE are typically provided by JPRT using the Windows mixed path (c:/jprt/...). We would like to stop using a special version of gnu make in JPRT to handle paths with colon in them. The solution is to convert these paths before trying to use them. Bug: https://bugs.openjdk.java.net/browse/JDK-8043127 Patch inline: diff -r b84fc0b1efc2 make/Jprt.gmk --- a/make/Jprt.gmk +++ b/make/Jprt.gmk @@ -23,8 +23,22 @@ # questions. # -# This file is contains targets utilities needed by JPRT. +# This file contains targets and utilities needed by JPRT. +# Cygpath is only defined when running on Cygwin +ifneq ($(CYGPATH), ) + # If we get JPRT_ARCHIVE_*BUNDLE externally, make sure they have /cygdrive + # style paths + ifdef JPRT_ARCHIVE_BUNDLE + override JPRT_ARCHIVE_BUNDLE := $(shell $(CYGPATH) -u $(JPRT_ARCHIVE_BUNDLE)) + endif + ifdef JPRT_ARCHIVE_INSTALL_BUNDLE + override JPRT_ARCHIVE_INSTALL_BUNDLE := $(shell $(CYGPATH) -u $(JPRT_ARCHIVE_INSTALL_BUNDLE)) + endif +endif + +# When running in JPRT these will be provided. Need defaults so that this makefile +# is valid anyway. ifndef JPRT_ARCHIVE_BUNDLE JPRT_ARCHIVE_BUNDLE=/tmp/jprt_bundles/j2sdk-image.zip endif From pointo1d at gmail.com Wed May 14 13:22:12 2014 From: pointo1d at gmail.com (pointo1d) Date: Wed, 14 May 2014 14:22:12 +0100 Subject: RFR: JDK-8043127: Convert JPRT_ARCHIVE_BUNDLE to unix style paths In-Reply-To: <5373626C.9000101@oracle.com> References: <5373626C.9000101@oracle.com> Message-ID: <53736E04.1000504@gmail.com> Hi Erik , On 14/05/14 13:32, Erik Joelsson wrote: > Hello, > > Please review this minor fix for jdk9. The input variables > JPRT_ARCHIVE_BUNDLE and JPRT_ARCHIVE_INSTALL_BUNDLE are typically > provided by JPRT using the Windows mixed path (c:/jprt/...). We would > like to stop using a special version of gnu make in JPRT to handle > paths with colon in them. The solution is to convert these paths > before trying to use them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043127 > Patch inline: > > diff -r b84fc0b1efc2 make/Jprt.gmk > --- a/make/Jprt.gmk > +++ b/make/Jprt.gmk > @@ -23,8 +23,22 @@ > # questions. > # > > -# This file is contains targets utilities needed by JPRT. > +# This file contains targets and utilities needed by JPRT. > > +# Cygpath is only defined when running on Cygwin > +ifneq ($(CYGPATH), ) > + # If we get JPRT_ARCHIVE_*BUNDLE externally, make sure they have > /cygdrive > + # style paths > + ifdef JPRT_ARCHIVE_BUNDLE > + override JPRT_ARCHIVE_BUNDLE := $(shell $(CYGPATH) -u > $(JPRT_ARCHIVE_BUNDLE)) > + endif > + ifdef JPRT_ARCHIVE_INSTALL_BUNDLE > + override JPRT_ARCHIVE_INSTALL_BUNDLE := $(shell $(CYGPATH) -u > $(JPRT_ARCHIVE_INSTALL_BUNDLE)) > + endif > +endif > + > +# When running in JPRT these will be provided. Need defaults so that > this makefile > +# is valid anyway. > ifndef JPRT_ARCHIVE_BUNDLE > JPRT_ARCHIVE_BUNDLE=/tmp/jprt_bundles/j2sdk-image.zip > endif > Altho' not a reviewer in the formal sense, pls be advised this seems eminently sensible and indeed, looks fine. -- 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 From mike.duigou at oracle.com Wed May 14 22:26:48 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 May 2014 15:26:48 -0700 Subject: RFR: 8043182: hgforest.sh: syntax error on line 329 Message-ID: <4FD87AF4-E0DA-4374-B993-4F23C627DE82@oracle.com> Hello all; A very small but high priority changeset. A stray ")" snuck in and was missed by both me and reviewers of JDK-8042810. http://cr.openjdk.java.net/~mduigou/JDK-8043182/0/webrev/ Wouldn't it be cool if there was a tool which validated the syntax of your source code long before it needed to be run and perhaps compiled it into a more efficient form... Mike From joe.darcy at oracle.com Wed May 14 23:12:51 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 May 2014 16:12:51 -0700 Subject: RFR: 8043182: hgforest.sh: syntax error on line 329 In-Reply-To: <4FD87AF4-E0DA-4374-B993-4F23C627DE82@oracle.com> References: <4FD87AF4-E0DA-4374-B993-4F23C627DE82@oracle.com> Message-ID: <5373F873.6000103@oracle.com> On 05/14/2014 03:26 PM, Mike Duigou wrote: > Hello all; > > A very small but high priority changeset. A stray ")" snuck in and was missed by both me and reviewers of JDK-8042810. > > http://cr.openjdk.java.net/~mduigou/JDK-8043182/0/webrev/ > > Wouldn't it be cool if there was a tool which validated the syntax of your source code long before it needed to be run and perhaps compiled it into a more efficient form... > > Mike Hi Mike, Looks good to go back; cheers, -Joe From tim.bell at oracle.com Thu May 15 01:18:32 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 15 May 2014 01:18:32 +0000 Subject: RFR: JDK-8043127: Convert JPRT_ARCHIVE_BUNDLE to unix style paths In-Reply-To: <5373626C.9000101@oracle.com> References: <5373626C.9000101@oracle.com> Message-ID: <537415E8.2090809@oracle.com> Hi Erik: > Please review this minor fix for jdk9. The input variables > JPRT_ARCHIVE_BUNDLE and JPRT_ARCHIVE_INSTALL_BUNDLE are typically > provided by JPRT using the Windows mixed path (c:/jprt/...). We would > like to stop using a special version of gnu make in JPRT to handle > paths with colon in them. The solution is to convert these paths > before trying to use them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043127 > Patch inline: Looks good to me. Tim > diff -r b84fc0b1efc2 make/Jprt.gmk > --- a/make/Jprt.gmk > +++ b/make/Jprt.gmk > @@ -23,8 +23,22 @@ > # questions. > # > > -# This file is contains targets utilities needed by JPRT. > +# This file contains targets and utilities needed by JPRT. > > +# Cygpath is only defined when running on Cygwin > +ifneq ($(CYGPATH), ) > + # If we get JPRT_ARCHIVE_*BUNDLE externally, make sure they have > /cygdrive > + # style paths > + ifdef JPRT_ARCHIVE_BUNDLE > + override JPRT_ARCHIVE_BUNDLE := $(shell $(CYGPATH) -u > $(JPRT_ARCHIVE_BUNDLE)) > + endif > + ifdef JPRT_ARCHIVE_INSTALL_BUNDLE > + override JPRT_ARCHIVE_INSTALL_BUNDLE := $(shell $(CYGPATH) -u > $(JPRT_ARCHIVE_INSTALL_BUNDLE)) > + endif > +endif > + > +# When running in JPRT these will be provided. Need defaults so that > this makefile > +# is valid anyway. > ifndef JPRT_ARCHIVE_BUNDLE > JPRT_ARCHIVE_BUNDLE=/tmp/jprt_bundles/j2sdk-image.zip > endif > From ioi.lam at oracle.com Thu May 15 04:53:22 2014 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 14 May 2014 21:53:22 -0700 Subject: How to disable demos In-Reply-To: <5371CF58.2080101@oracle.com> References: <53718AD9.60309@oracle.com> <5371CF58.2080101@oracle.com> Message-ID: <53744842.5080401@oracle.com> Hi Erik, I need to build image and I do this quite often. On Windows, make demos takes a minute or so on a fast machine. It's not too long, but still kind of annoying. I will try to save a copy of the various demos output and do something like make jdk; unzip -D ../demos.zip; make images - Ioi On 5/13/14, 12:52 AM, Erik Joelsson wrote: > Hello, > > No, not really. If you do "make jdk" (or just "make" which is the > same), demos aren't built. If you do "make images" or "make demos", > the demos are built. What is your usecase? If you don't need images, > then you are already skipping demos. If you need images, then demos > will be built the first time. Building the demos is quite fast these > days so we figured it would be better to reduce the complexity of > handling builds with or without demos. > > /Erik > > On 2014-05-13 05:00, Ioi Lam wrote: >> I tried the NO_DEMOS flag as in >> https://bugs.openjdk.java.net/browse/JDK-7143162 "Allow disabling of >> jdk demos and samples build", but this seems to be in "old build" >> only, and doesn't affect the new build system. >> >> Is there an equivalent for the new build? >> >> Thanks >> >> - Ioi > From pointo1d at gmail.com Thu May 15 10:13:09 2014 From: pointo1d at gmail.com (pointo1d) Date: Thu, 15 May 2014 11:13:09 +0100 Subject: RFR: 8043182: hgforest.sh: syntax error on line 329 In-Reply-To: <4FD87AF4-E0DA-4374-B993-4F23C627DE82@oracle.com> References: <4FD87AF4-E0DA-4374-B993-4F23C627DE82@oracle.com> Message-ID: <53749335.3080801@gmail.com> Hiya Mike , On 14/05/14 23:26, Mike Duigou wrote: > Hello all; > > A very small but high priority changeset. A stray ")" snuck in and was missed by both me and reviewers of JDK-8042810. > > http://cr.openjdk.java.net/~mduigou/JDK-8043182/0/webrev/ > > Wouldn't it be cool if there was a tool which validated the syntax of your source code long before it needed to be run and perhaps compiled it into a more efficient form... 'sh -c' works most of the time for me - until it's a script that contains an endless loops that is conditionally terminated. As for compilation, I think I might've mentioned the use of perl(1) before ... :-) > Mike 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 From omajid at redhat.com Sat May 17 00:45:30 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 16 May 2014 20:45:30 -0400 Subject: RFR: Allow using the system libjpeg Message-ID: <20140517004529.GD4370@redhat.com> Hi, Webrevs are at: http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00 http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk This patch modifies OpenJDK to allow building and running using the system copy of libjpeg. This follows my previous changes for lcms and a lot of the decisions made on that patch apply here. This is the last of my system-library patches :) Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From mike.duigou at oracle.com Sat May 17 03:37:56 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 16 May 2014 20:37:56 -0700 Subject: RFR: Allow using the system libjpeg In-Reply-To: <20140517004529.GD4370@redhat.com> References: <20140517004529.GD4370@redhat.com> Message-ID: <8A315662-FB18-4387-908A-B93AC1A2E395@oracle.com> [not a review] On May 16 2014, at 17:45 , Omair Majid wrote: > Hi, > > Webrevs are at: > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00 > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk > > This patch modifies OpenJDK to allow building and running using the > system copy of libjpeg. This follows my previous changes for lcms > and a lot of the decisions made on that patch apply here. > > This is the last of my system-library patches :) A very useful contribution! Mike From anthony.petrov at oracle.com Mon May 19 18:42:38 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 19 May 2014 22:42:38 +0400 Subject: RFR: Allow using the system libjpeg In-Reply-To: <20140517004529.GD4370@redhat.com> References: <20140517004529.GD4370@redhat.com> Message-ID: <537A509E.2090504@oracle.com> Hi Omair, common/autoconf/libraries.m4 > 624 [use libjpeg from build system or OpenJDK source (system, bundled) @<:bundled@:>@])]) "@<:bundled@:>@" should read "@<:@bundled@:>@" - note the missing @. make/lib/Awt2dLibraries.gmk > 1236 LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg Since these are compiler flags, I suppose this should read "-I", not just "". Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg files? -- best regards, Anthony On 5/17/2014 4:45 AM, Omair Majid wrote: > Hi, > > Webrevs are at: > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00 > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/00.jdk > > This patch modifies OpenJDK to allow building and running using the > system copy of libjpeg. This follows my previous changes for lcms > and a lot of the decisions made on that patch apply here. > > This is the last of my system-library patches :) > > Thanks, > Omair > From mike.duigou at oracle.com Tue May 20 00:50:34 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 May 2014 17:50:34 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: References: <531F05D3.6020008@oracle.com> Message-ID: <6A7B5F26-FE6C-439E-8C40-4BEE2DD739C7@oracle.com> I am running final (I _really_ hope) tests on this issue but had to make a few changes to the hotspot makefiles: The patch has been enhanced since the last revision to ensure that the linker flags are incorporated into the actual linker flags for fastdebug mode. Previously this was only being done on Solaris due to unexpected behavioural differences between the platform's makefiles. The bsd, linux and solaris makefiles now handle the FASTDEBUG_CFLAGS the same way. I've also checked and don't believe that changing the handling of FASTDEBUG_CFLAGS resulted in any unexpected flag changes. http://cr.openjdk.java.net/~mduigou/JDK-8032045/7/webrev/ Mike On May 8 2014, at 12:13 , Mike Duigou wrote: > Ping. Still needing reviewers on this issue. > > I plan to push this change through the hotspot-rt repo. > > Mike > > On May 3 2014, at 20:24 , Mike Duigou wrote: > >> Hello; >> >> Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. >> >> This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. >> >> https://bugs.openjdk.java.net/browse/JDK-8032045 >> http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ >> >> Mike >> >> On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: >> >>> On 2014-03-11 00:49, Mike Duigou wrote: >>>> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>>> >>>> This version is, hopefully, almost ready to be pushed. >>> >>> I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. >>> >>> The top-level build changes looks fine. Thank you Mike for cleaning things up! >>> >>> /Magnus >>> >>>> >>>> Mike >>>> >>>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>>>> >>>>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>>>> >>>>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>>>> >>>>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>>>> >>>>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>>>> >>>>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>>> >>>>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>>> >>>>> Thanks, >>>>> >>>>> Mike >>> >> > From vladimir.kozlov at oracle.com Tue May 20 01:45:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 May 2014 18:45:33 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <6A7B5F26-FE6C-439E-8C40-4BEE2DD739C7@oracle.com> References: <531F05D3.6020008@oracle.com> <6A7B5F26-FE6C-439E-8C40-4BEE2DD739C7@oracle.com> Message-ID: <537AB3BD.9060708@oracle.com> Looks fine to me. We don't use gcc on Solaris. How you tested solaris/makefiles/gcc.make changes? Thanks, Vladimir On 5/19/14 5:50 PM, Mike Duigou wrote: > I am running final (I _really_ hope) tests on this issue but had to make a few changes to the hotspot makefiles: > > The patch has been enhanced since the last revision to ensure that the linker flags are incorporated into the actual linker flags for fastdebug mode. Previously this was only being done on Solaris due to unexpected behavioural differences between the platform's makefiles. The bsd, linux and solaris makefiles now handle the FASTDEBUG_CFLAGS the same way. I've also checked and don't believe that changing the handling of FASTDEBUG_CFLAGS resulted in any unexpected flag changes. > > http://cr.openjdk.java.net/~mduigou/JDK-8032045/7/webrev/ > > Mike > > On May 8 2014, at 12:13 , Mike Duigou wrote: > >> Ping. Still needing reviewers on this issue. >> >> I plan to push this change through the hotspot-rt repo. >> >> Mike >> >> On May 3 2014, at 20:24 , Mike Duigou wrote: >> >>> Hello; >>> >>> Finally getting back to this issue I have done some cleanup and adjusted the hotspot gcc.make files to use VARIANT rather than DEBUG_LEVEL. >>> >>> This version also add support for the "-fsanitize=undefined" undefined behaviour warnings feature when it is available (Clang and GCC 4.9). The code to emit the option has been added for Clang but I haven't yet added test for the option's availability under Clang so currently it will be enabled only for GCC. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/6/webrev/ >>> >>> Mike >>> >>> On Mar 11 2014, at 05:47 , Magnus Ihse Bursie wrote: >>> >>>> On 2014-03-11 00:49, Mike Duigou wrote: >>>>> I have updated the patch to respond to Magnus's feedback and to accommodate intervening changes to the configure and hotspot make files. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/3/webrev/ >>>>> >>>>> This version is, hopefully, almost ready to be pushed. >>>> >>>> I have only glanced at the hotspot build changes and can't really say anything about them. The hotspot team still owns these; I'm cc:ing them now. >>>> >>>> The top-level build changes looks fine. Thank you Mike for cleaning things up! >>>> >>>> /Magnus >>>> >>>>> >>>>> Mike >>>>> >>>>> On Feb 20 2014, at 15:43 , Mike Duigou wrote: >>>>> >>>>>> Hello all; >>>>>> >>>>>> This issue is a followon to JDK-8030350 (https://bugs.openjdk.java.net/browse/JDK-8030350) which enhanced the compiler warnings used for compiling native code. The proposed changes principally impact the Linux platform. >>>>>> >>>>>> While 8030350 was focused on compiler warnings which did not impact code generation, this changeset will, for some configurations, change the native code generated and likely change performance. These proposed option changes prevent specific types of relocation table, stack and heap memory corruption in native code. Preventing these types of memory corruption may be useful for finding certain kinds of bugs though and do provide some minimal additional protections against malicious attacks. They aren't, by any means, a substitute for following appropriate secure coding guidelines. >>>>>> >>>>>> The rationale behind the implementation is as follows. For release builds during the initial phase of JDK 9 I would like to enable only compile time checks. This ends up being similar to the warnings in JDK-8030350. These options have no runtime impact on footprint or performance and very minimal additional compile time cost while providing value. **Release builds are not expected to see any performance or footprint change as a result of this changeset** >>>>>> >>>>>> For fast debug builds we can enable linker protections (relro) and static compile time bounds checks (FORTIFY_SOURCE=1). FORTIFY_SOURCE=1 might be moved to the production builds as well because it has no runtime cost or executable size cost. >>>>>> >>>>>> For slow debug builds we can enable full linker protection (at a potential cost in startup time), runtime bounds checks and stack protection (FORTIFY_SOURCE=2 -fprotect-stack-all). We will likely enable -fprotect-stack-strong when available in GCC 4.9 >>>>>> >>>>>> The basis for enabling the additional protections in debug builds is that it will help us find bugs in our native code and we aren't as concerned in debug builds with footprint and performance. Since many developers already do their personal builds in fastdebug or slowdebug mode for testing this will provide good opportunity to shake out any problems with the options while not impacting release builds. Should we find that any of the options provide significant value for their cost we can move them to fastdebug or release. If any of the options prove too costly they can be demoted or removed entirely. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8032045 >>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8032045/2/webrev/ >>>>>> >>>>>> Additional to enabling the various compiler options I attempted to rationalize some of the skew between the various hotspot/make/{platform}/makefiles/gcc.make files while avoiding changing existing behaviour. I have also introduced the new -Og "optimize for debugging" option and there are now an explicit C{XX}_O_FLAG_DEBUG definitions to complement the C{XX}_O_FLAG_{DEBUG|NORM|HI|HIGHEST|NONE} optimization options. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Mike >>>> >>> >> > From mike.duigou at oracle.com Tue May 20 02:14:59 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 May 2014 19:14:59 -0700 Subject: RFR : JDK-8032045 : (m/l) Enable compiler and linker safety switches for debug builds In-Reply-To: <537AB3BD.9060708@oracle.com> References: <531F05D3.6020008@oracle.com> <6A7B5F26-FE6C-439E-8C40-4BEE2DD739C7@oracle.com> <537AB3BD.9060708@oracle.com> Message-ID: On May 19 2014, at 18:45 , Vladimir Kozlov wrote: > Looks fine to me. > > We don't use gcc on Solaris. How you tested solaris/makefiles/gcc.make changes? I have not been able to test the Solaris changes. It is my understanding that the gcc on solaris makefiles have not been tested in some time and have quite likely bit-rotted. I tried to transplant changes between linux and bsd into Solaris in as conservative a fashion as possible but I did want to avoid additional skew between the solaris, bsd and linux gcc.make files. Mike From omajid at redhat.com Tue May 20 17:11:20 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 20 May 2014 13:11:20 -0400 Subject: RFR: Allow using the system libjpeg In-Reply-To: <537A509E.2090504@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> Message-ID: <20140520171120.GD2672@redhat.com> Hi, Updated webrevs: http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/ http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/ * Anthony Petrov [2014-05-19 14:42]: > make/lib/Awt2dLibraries.gmk > >1236 LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg > > Since these are compiler flags, I suppose this should read "-I", not > just "". Yes, it should. I wonder how my compiler accepted that. > Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg > files? I did. I tested both combinations and made sure both the splash screen and javax.swing.ImageIcon could display jpegs files with the first webrev I posted. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From anthony.petrov at oracle.com Tue May 20 17:15:11 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 20 May 2014 21:15:11 +0400 Subject: RFR: Allow using the system libjpeg In-Reply-To: <20140520171120.GD2672@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> Message-ID: <537B8D9F.5000007@oracle.com> Thanks for the update, Omair. The fix looks good to me now. -- best regards, Anthony On 5/20/2014 9:11 PM, Omair Majid wrote: > Hi, > > Updated webrevs: > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/ > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/ > > * Anthony Petrov [2014-05-19 14:42]: >> make/lib/Awt2dLibraries.gmk >>> 1236 LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg >> >> Since these are compiler flags, I suppose this should read "-I", not >> just "". > > Yes, it should. I wonder how my compiler accepted that. > >> Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg >> files? > > I did. I tested both combinations and made sure both the splash screen > and javax.swing.ImageIcon could display jpegs files with the first > webrev I posted. > > Thanks, > Omair > From philip.race at oracle.com Tue May 20 17:18:44 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 20 May 2014 10:18:44 -0700 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <537B8D9F.5000007@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <537B8D9F.5000007@oracle.com> Message-ID: <537B8E74.9050306@oracle.com> I'm going to apply the patch and run it through open + closed builds cross-platforms .. -phil.. On 5/20/2014 10:15 AM, Anthony Petrov wrote: > Thanks for the update, Omair. The fix looks good to me now. > > -- > best regards, > Anthony > > On 5/20/2014 9:11 PM, Omair Majid wrote: >> Hi, >> >> Updated webrevs: >> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/ >> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/ >> >> * Anthony Petrov [2014-05-19 14:42]: >>> make/lib/Awt2dLibraries.gmk >>>> 1236 LIBJPEG_CFLAGS := >>>> $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg >>> >>> Since these are compiler flags, I suppose this should read >>> "-I", not >>> just "". >> >> Yes, it should. I wonder how my compiler accepted that. >> >>> Did you build with --with-jpeg=bundled ? Can the resulting JDK read >>> jpeg >>> files? >> >> I did. I tested both combinations and made sure both the splash screen >> and javax.swing.ImageIcon could display jpegs files with the first >> webrev I posted. >> >> Thanks, >> Omair >> From philip.race at oracle.com Tue May 20 22:33:40 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 20 May 2014 15:33:40 -0700 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <537B8E74.9050306@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <537B8D9F.5000007@oracle.com> <537B8E74.9050306@oracle.com> Message-ID: <537BD844.7060109@oracle.com> I only tried the default (not specifying the system libjpeg) but my builds all succeeded and SwingSet & Java2D demo ran fine on Mac & Windows with the closed builds (after generating a closed generated-configure.sh) so this all looks good to push. I will need to push that closed generated-configure.sh afterwards however so that closed builds don't break. -phil. On 05/20/2014 10:18 AM, Phil Race wrote: > I'm going to apply the patch and run it through open + closed builds > cross-platforms .. > > -phil.. > > On 5/20/2014 10:15 AM, Anthony Petrov wrote: >> Thanks for the update, Omair. The fix looks good to me now. >> >> -- >> best regards, >> Anthony >> >> On 5/20/2014 9:11 PM, Omair Majid wrote: >>> Hi, >>> >>> Updated webrevs: >>> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/ >>> http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/ >>> >>> * Anthony Petrov [2014-05-19 14:42]: >>>> make/lib/Awt2dLibraries.gmk >>>>> 1236 LIBJPEG_CFLAGS := >>>>> $(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg >>>> >>>> Since these are compiler flags, I suppose this should read >>>> "-I", not >>>> just "". >>> >>> Yes, it should. I wonder how my compiler accepted that. >>> >>>> Did you build with --with-jpeg=bundled ? Can the resulting JDK read >>>> jpeg >>>> files? >>> >>> I did. I tested both combinations and made sure both the splash screen >>> and javax.swing.ImageIcon could display jpegs files with the first >>> webrev I posted. >>> >>> Thanks, >>> Omair >>> > From daniel.smith at oracle.com Tue May 20 22:42:07 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 20 May 2014 16:42:07 -0600 Subject: Can't build hotspot with Xcode 4 Message-ID: Starting today, if I configure with Xcode 4 on OS X 10.9, I can no longer build jdk9/dev/hotspot (changeset b329ff11a78c). make dist-clean sh configure --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin --with-toolchain-type=gcc --with-boot-jdk=$JAVA8_HOME make images ... cc1plus: warnings being treated as errors In file included from ../generated/tracefiles/traceEventClasses.hpp:19, from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/trace/tracing.hpp:28, from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/opto/compile.hpp:43, from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/opto/node.hpp:29, from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/opto/addnode.hpp:28, from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:252: /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/trace/traceStream.hpp: In member function ?void TraceStream::print_val(const char*, s8)?: /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/trace/traceStream.hpp:69: warning: format ?%lld? expects type ?long long int?, but argument 4 has type ?s8? Fortunately, I can now cleanly build with Xcode 5: make dist-clean sh configure --with-boot-jdk=$JAVA8_HOME make images However, I don't know if it is intentional that Xcode 4 support is being dropped. ?Dan From david.dehaven at oracle.com Wed May 21 03:08:58 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 20 May 2014 20:08:58 -0700 Subject: Can't build hotspot with Xcode 4 In-Reply-To: References: Message-ID: <8E833BF1-B2E0-4850-A5F2-C55DF6F8DF0B@oracle.com> > Starting today, if I configure with Xcode 4 on OS X 10.9, I can no longer build jdk9/dev/hotspot (changeset b329ff11a78c). > > make dist-clean > sh configure --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin --with-toolchain-type=gcc --with-boot-jdk=$JAVA8_HOME > make images > > ... > cc1plus: warnings being treated as errors > In file included from ../generated/tracefiles/traceEventClasses.hpp:19, > from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/trace/tracing.hpp:28, > from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/opto/compile.hpp:43, > from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/opto/node.hpp:29, > from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/opto/addnode.hpp:28, > from /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/precompiled/precompiled.hpp:252: > /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/trace/traceStream.hpp: In member function ?void TraceStream::print_val(const char*, s8)?: > /Users/dan/Dev/jdk/jdk9/hotspot/src/share/vm/trace/traceStream.hpp:69: warning: format ?%lld? expects type ?long long int?, but argument 4 has type ?s8? > > Fortunately, I can now cleanly build with Xcode 5: > > make dist-clean > sh configure --with-boot-jdk=$JAVA8_HOME > make images > > However, I don't know if it is intentional that Xcode 4 support is being dropped. No, I don't think so. There were two fixes integrated from hotspot: https://bugs.openjdk.java.net/browse/JDK-8037816 https://bugs.openjdk.java.net/browse/JDK-8043029 And two more issues in hotspot that didn't make it to this weeks party: https://bugs.openjdk.java.net/browse/JDK-8043033 https://bugs.openjdk.java.net/browse/JDK-8043164 You could pull those changesets from jdk9/hs/hotspot and see if that fixes the issue (I haven't tried that but it should be OK). But... ideally Xcode 5 should be used on 10.9, the only case where that isn't true is if you're building 8u. For 7u and earlier just stick with 10.8 and Xcode 4.6.3, it's not worth the hassle. I have a change I'm going to post for review here sometime in the next week to fix the header/framework location issue so clean 10.9/Xcode 5 installs will (finally) be able to build without modifying the system. Oh, and my X11 dependency removal change is sitting in jdk9/client, which should make it's way over to jdk9/dev next week. Once that's done you can remove XQuartz... I will backport those to 8u, but they need some time to bake first. -DrD- From david.dehaven at oracle.com Wed May 21 04:30:49 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 20 May 2014 21:30:49 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework Message-ID: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8043340 Summary: We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. Changes of note: - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" - Changed all -F arguments to -F$(MAC_SDK_PATH) - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. Patches: http://cr.openjdk.java.net/~ddehaven/8043340/v0/top http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk -DrD- From mike.duigou at oracle.com Wed May 21 04:52:54 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 20 May 2014 21:52:54 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> Message-ID: <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> [not a build project Reviewer] The only change I would make is to put a conditional around the other new variable in spec.gmk.in. I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. Mike On May 20, 2014, at 9:30 PM, David DeHaven wrote: > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8043340 > > Summary: > We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. > > Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. > > Changes of note: > - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" > - Changed all -F arguments to -F$(MAC_SDK_PATH) > - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. > - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) > - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers > - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers > > Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. > > Patches: > http://cr.openjdk.java.net/~ddehaven/8043340/v0/top > http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot > http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk > > -DrD- > From david.dehaven at oracle.com Wed May 21 04:56:44 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 20 May 2014 21:56:44 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> Message-ID: <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> I can do both of those. It's MacOSX.sdk, e.g., MacOSX10.9.sdk so MACOSX_SDK_PATH does make more sense. -DrD- > [not a build project Reviewer] > > The only change I would make is to put a conditional around the other new variable in spec.gmk.in. > > I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. > > Mike > > On May 20, 2014, at 9:30 PM, David DeHaven wrote: > >> >> JBS Issue: >> https://bugs.openjdk.java.net/browse/JDK-8043340 >> >> Summary: >> We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. >> >> Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. >> >> Changes of note: >> - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" >> - Changed all -F arguments to -F$(MAC_SDK_PATH) >> - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. >> - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) >> - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers >> - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers >> >> Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. >> >> Patches: >> http://cr.openjdk.java.net/~ddehaven/8043340/v0/top >> http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot >> http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk >> >> -DrD- >> From erik.joelsson at oracle.com Wed May 21 08:08:44 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 May 2014 10:08:44 +0200 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> Message-ID: <537C5F0C.3090801@oracle.com> Hello David, Mostly looks good. I don't see a reason to add ifeqs on OS around variables in spec.gmk.in. We usually just leave them there for all platforms. The only difference that will make is the variable will be undefined instead of empty. Variable name as suggested by Mike seems fine to me. /Erik On 2014-05-21 06:56, David DeHaven wrote: > I can do both of those. It's MacOSX.sdk, e.g., MacOSX10.9.sdk so MACOSX_SDK_PATH does make more sense. > > -DrD- > >> [not a build project Reviewer] >> >> The only change I would make is to put a conditional around the other new variable in spec.gmk.in. >> >> I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. >> >> Mike >> >> On May 20, 2014, at 9:30 PM, David DeHaven wrote: >> >>> JBS Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>> >>> Summary: >>> We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. >>> >>> Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. >>> >>> Changes of note: >>> - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" >>> - Changed all -F arguments to -F$(MAC_SDK_PATH) >>> - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. >>> - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) >>> - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers >>> - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers >>> >>> Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. >>> >>> Patches: >>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/top >>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot >>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk >>> >>> -DrD- >>> From omajid at redhat.com Wed May 21 15:06:04 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 21 May 2014 11:06:04 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <537BD844.7060109@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <537B8D9F.5000007@oracle.com> <537B8E74.9050306@oracle.com> <537BD844.7060109@oracle.com> Message-ID: <20140521150604.GB3957@redhat.com> Hi, * Phil Race [2014-05-20 18:34]: > I only tried the default (not specifying the system libjpeg) but my builds > all succeeded and SwingSet & Java2D demo ran fine on Mac & Windows > with the closed builds (after generating a closed generated-configure.sh) > so this all looks good to push. Thanks for testing! > I will need to push that closed generated-configure.sh afterwards however > so that closed builds don't break. Anything I need to do to ensure the pushes are co-ordinated correctly? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed May 21 16:21:39 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 May 2014 12:21:39 -0400 (EDT) Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <20140520171120.GD2672@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> Message-ID: <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > Updated webrevs: > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/ > http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/ > > * Anthony Petrov [2014-05-19 14:42]: > > make/lib/Awt2dLibraries.gmk > > >1236 LIBJPEG_CFLAGS := > > >$(JDK_TOPDIR)/src/share/native/sun/awt/image/jpeg > > > > Since these are compiler flags, I suppose this should read "-I", not > > just "". > > Yes, it should. I wonder how my compiler accepted that. > > > Did you build with --with-jpeg=bundled ? Can the resulting JDK read jpeg > > files? > > I did. I tested both combinations and made sure both the splash screen > and javax.swing.ImageIcon could display jpegs files with the first > webrev I posted. > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > I'm not keen on the hardcoding of '-ljpeg' + LIBJPEG_LIBS := -ljpeg Could this not at least be conditionally assigned? (?=) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.dehaven at oracle.com Wed May 21 16:33:25 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 21 May 2014 09:33:25 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <537C5F0C.3090801@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> Message-ID: As long as XCODEBUILD=@XCODEBUILD@ doesn't result in an error on other platforms, that was my only concern there. -DrD- > Hello David, > > Mostly looks good. I don't see a reason to add ifeqs on OS around variables in spec.gmk.in. We usually just leave them there for all platforms. The only difference that will make is the variable will be undefined instead of empty. > > Variable name as suggested by Mike seems fine to me. > > /Erik > > On 2014-05-21 06:56, David DeHaven wrote: >> I can do both of those. It's MacOSX.sdk, e.g., MacOSX10.9.sdk so MACOSX_SDK_PATH does make more sense. >> >> -DrD- >> >>> [not a build project Reviewer] >>> >>> The only change I would make is to put a conditional around the other new variable in spec.gmk.in. >>> >>> I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. >>> >>> Mike >>> >>> On May 20, 2014, at 9:30 PM, David DeHaven wrote: >>> >>>> JBS Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>>> >>>> Summary: >>>> We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. >>>> >>>> Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. >>>> >>>> Changes of note: >>>> - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" >>>> - Changed all -F arguments to -F$(MAC_SDK_PATH) >>>> - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. >>>> - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) >>>> - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers >>>> - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers >>>> >>>> Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. >>>> >>>> Patches: >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/top >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk >>>> >>>> -DrD- >>>> > From philip.race at oracle.com Wed May 21 18:29:17 2014 From: philip.race at oracle.com (Phil Race) Date: Wed, 21 May 2014 11:29:17 -0700 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <20140521150604.GB3957@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <537B8D9F.5000007@oracle.com> <537B8E74.9050306@oracle.com> <537BD844.7060109@oracle.com> <20140521150604.GB3957@redhat.com> Message-ID: <537CF07D.6050801@oracle.com> On 05/21/2014 08:06 AM, Omair Majid wrote: > > I will need to push that closed generated-configure.sh afterwards however > so that closed builds don't break. > Anything I need to do to ensure the pushes are co-ordinated correctly? Just make sure I notice the push and I'll fix ASAP .. -phil. From omajid at redhat.com Wed May 21 20:59:35 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 21 May 2014 16:59:35 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> Message-ID: <20140521205934.GE3957@redhat.com> * Andrew Hughes [2014-05-21 12:22]: > I'm not keen on the hardcoding of '-ljpeg' > > + LIBJPEG_LIBS := -ljpeg There's no pkg-config files for it. Any suggestions on how to get something generic? > Could this not at least be conditionally assigned? (?=) It can still be overridden on the make command line: make LIBJPEG_LIBS=foo Is this not sufficient? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.dehaven at oracle.com Wed May 21 21:23:28 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 21 May 2014 14:23:28 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> Message-ID: <2079E864-F1AD-4D17-B712-6563B50A7CEC@oracle.com> > Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. I just ran into an issue in hotspot with Xcode 5.1 on 10.8 with older command line tools (from Xcode 4) installed. We'll need to use -isysroot in conjunction with -iframeworks I'll update the patches with this and the recommendations I've gotten so far tonight. -DrD- From gnu.andrew at redhat.com Thu May 22 00:23:23 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 May 2014 20:23:23 -0400 (EDT) Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <20140521205934.GE3957@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> Message-ID: <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> ----- Original Message ----- > * Andrew Hughes [2014-05-21 12:22]: > > I'm not keen on the hardcoding of '-ljpeg' > > > > + LIBJPEG_LIBS := -ljpeg > > There's no pkg-config files for it. Any suggestions on how to get > something generic? > I know there isn't at present. I still think it's better to be consistent and set the values in configure, even if at present they have to be hardcoded defaults. > > Could this not at least be conditionally assigned? (?=) > > It can still be overridden on the make command line: > > make LIBJPEG_LIBS=foo > > Is this not sufficient? > The make documentation is a little unclear here, and makes it sound like it will always be set if := or = is used. > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Thu May 22 00:49:31 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 21 May 2014 20:49:31 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> Message-ID: <20140522004931.GG3957@redhat.com> * Andrew Hughes [2014-05-21 20:23]: > ----- Original Message ----- > > * Andrew Hughes [2014-05-21 12:22]: > > > I'm not keen on the hardcoding of '-ljpeg' > > > > > > + LIBJPEG_LIBS := -ljpeg > > > > There's no pkg-config files for it. Any suggestions on how to get > > something generic? > > > > I know there isn't at present. I still think it's better to be consistent > and set the values in configure, even if at present they have to be hardcoded > defaults. Would you mind if I did this as a separate patch? I will need to fix other libraries too (libzip, and libgif). > The make documentation is a little unclear here, and makes it sound like it > will always be set if := or = is used. Indeed, it is unclear. But I discovered through trial and error that given a Makefile like: FOO=-v all: gcc ${FOO} these two forms are different: $ FOO=bar make $ make FOO=bar The first one sets the environment variable FOO, and the Makefile overrides it (it runs `gcc -v`). The second passes a command line argument that overrides the value in the Makefile (it runs `gcc foo`). Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From erik.joelsson at oracle.com Thu May 22 08:57:47 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 May 2014 10:57:47 +0200 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> Message-ID: <537DBC0B.9040408@oracle.com> We have several platform specific tools defined that way already (CYGPATH, MT, RC to name a few), so no worries. The error would be trying to use them on the wrong platform, but protecting the assignment won't help with that. /Erik On 2014-05-21 18:33, David DeHaven wrote: > As long as XCODEBUILD=@XCODEBUILD@ doesn't result in an error on other platforms, that was my only concern there. > > -DrD- > >> Hello David, >> >> Mostly looks good. I don't see a reason to add ifeqs on OS around variables in spec.gmk.in. We usually just leave them there for all platforms. The only difference that will make is the variable will be undefined instead of empty. >> >> Variable name as suggested by Mike seems fine to me. >> >> /Erik >> >> On 2014-05-21 06:56, David DeHaven wrote: >>> I can do both of those. It's MacOSX.sdk, e.g., MacOSX10.9.sdk so MACOSX_SDK_PATH does make more sense. >>> >>> -DrD- >>> >>>> [not a build project Reviewer] >>>> >>>> The only change I would make is to put a conditional around the other new variable in spec.gmk.in. >>>> >>>> I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. >>>> >>>> Mike >>>> >>>> On May 20, 2014, at 9:30 PM, David DeHaven wrote: >>>> >>>>> JBS Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>>>> >>>>> Summary: >>>>> We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. >>>>> >>>>> Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. >>>>> >>>>> Changes of note: >>>>> - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" >>>>> - Changed all -F arguments to -F$(MAC_SDK_PATH) >>>>> - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. >>>>> - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) >>>>> - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers >>>>> - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers >>>>> >>>>> Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. >>>>> >>>>> Patches: >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/top >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk >>>>> >>>>> -DrD- >>>>> From erik.joelsson at oracle.com Thu May 22 09:02:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 May 2014 11:02:04 +0200 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <20140522004931.GG3957@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> Message-ID: <537DBD0C.2010809@oracle.com> On 2014-05-22 02:49, Omair Majid wrote: > * Andrew Hughes [2014-05-21 20:23]: >> ----- Original Message ----- >>> * Andrew Hughes [2014-05-21 12:22]: >>>> I'm not keen on the hardcoding of '-ljpeg' >>>> >>>> + LIBJPEG_LIBS := -ljpeg >>> There's no pkg-config files for it. Any suggestions on how to get >>> something generic? >>> >> I know there isn't at present. I still think it's better to be consistent >> and set the values in configure, even if at present they have to be hardcoded >> defaults. > Would you mind if I did this as a separate patch? I will need to fix > other libraries too (libzip, and libgif). > >> The make documentation is a little unclear here, and makes it sound like it >> will always be set if := or = is used. > Indeed, it is unclear. But I discovered through trial and error that > given a Makefile like: > > FOO=-v > all: > gcc ${FOO} > > these two forms are different: > > $ FOO=bar make > > $ make FOO=bar > > The first one sets the environment variable FOO, and the Makefile > overrides it (it runs `gcc -v`). The second passes a command line > argument that overrides the value in the Makefile (it runs `gcc foo`). This is my experience too. There is the "override" keyword that you can use to not allow command line overrides: override FOO=-v The above would make both forms behave the same. /Erik > Thanks, > Omair > From david.dehaven at oracle.com Thu May 22 16:14:47 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 22 May 2014 09:14:47 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <537DBC0B.9040408@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> Message-ID: <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> Good point. I'm also wondering, what if (for whatever reason) MACOSX_SDK_PATH is empty? That will cause the -isysroot argument to be invalid. I can either make an undefined MACOSX_SDK_PATH a hard error (in configure) or I can wrap all uses of -isysroot/-iframework with ifneq blocks. Personally, I'd prefer the former, since there should never be a case where it can't find the SDK, if there is then the build environment is not set up correctly. I've not yet hit a case where it's been undefined, so I find it unlikely to be an issue if we make it a hard error. -DrD- > We have several platform specific tools defined that way already (CYGPATH, MT, RC to name a few), so no worries. The error would be trying to use them on the wrong platform, but protecting the assignment won't help with that. > > /Erik > > On 2014-05-21 18:33, David DeHaven wrote: >> As long as XCODEBUILD=@XCODEBUILD@ doesn't result in an error on other platforms, that was my only concern there. >> >> -DrD- >> >>> Hello David, >>> >>> Mostly looks good. I don't see a reason to add ifeqs on OS around variables in spec.gmk.in. We usually just leave them there for all platforms. The only difference that will make is the variable will be undefined instead of empty. >>> >>> Variable name as suggested by Mike seems fine to me. >>> >>> /Erik >>> >>> On 2014-05-21 06:56, David DeHaven wrote: >>>> I can do both of those. It's MacOSX.sdk, e.g., MacOSX10.9.sdk so MACOSX_SDK_PATH does make more sense. >>>> >>>> -DrD- >>>> >>>>> [not a build project Reviewer] >>>>> >>>>> The only change I would make is to put a conditional around the other new variable in spec.gmk.in. >>>>> >>>>> I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. >>>>> >>>>> Mike >>>>> >>>>> On May 20, 2014, at 9:30 PM, David DeHaven wrote: >>>>> >>>>>> JBS Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>>>>> >>>>>> Summary: >>>>>> We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. >>>>>> >>>>>> Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. >>>>>> >>>>>> Changes of note: >>>>>> - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" >>>>>> - Changed all -F arguments to -F$(MAC_SDK_PATH) >>>>>> - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. >>>>>> - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) >>>>>> - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers >>>>>> - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers >>>>>> >>>>>> Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. >>>>>> >>>>>> Patches: >>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/top >>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot >>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk >>>>>> >>>>>> -DrD- >>>>>> > From mike.duigou at oracle.com Thu May 22 16:24:32 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 22 May 2014 09:24:32 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> Message-ID: On May 22 2014, at 09:14 , David DeHaven wrote: > > Good point. > > I'm also wondering, what if (for whatever reason) MACOSX_SDK_PATH is empty? > > That will cause the -isysroot argument to be invalid. I can either make an undefined MACOSX_SDK_PATH a hard error (in configure) Earlier failure is better. > or I can wrap all uses of -isysroot/-iframework with ifneq blocks. Yuck. > Personally, I'd prefer the former, since there should never be a case where it can't find the SDK, if there is then the build environment is not set up correctly. I've not yet hit a case where it's been undefined, so I find it unlikely to be an issue if we make it a hard error. > > -DrD- > >> We have several platform specific tools defined that way already (CYGPATH, MT, RC to name a few), so no worries. The error would be trying to use them on the wrong platform, but protecting the assignment won't help with that. >> >> /Erik >> >> On 2014-05-21 18:33, David DeHaven wrote: >>> As long as XCODEBUILD=@XCODEBUILD@ doesn't result in an error on other platforms, that was my only concern there. >>> >>> -DrD- >>> >>>> Hello David, >>>> >>>> Mostly looks good. I don't see a reason to add ifeqs on OS around variables in spec.gmk.in. We usually just leave them there for all platforms. The only difference that will make is the variable will be undefined instead of empty. >>>> >>>> Variable name as suggested by Mike seems fine to me. >>>> >>>> /Erik >>>> >>>> On 2014-05-21 06:56, David DeHaven wrote: >>>>> I can do both of those. It's MacOSX.sdk, e.g., MacOSX10.9.sdk so MACOSX_SDK_PATH does make more sense. >>>>> >>>>> -DrD- >>>>> >>>>>> [not a build project Reviewer] >>>>>> >>>>>> The only change I would make is to put a conditional around the other new variable in spec.gmk.in. >>>>>> >>>>>> I wondered if the variable should be MACOS_SDK_PATH since macos.sdk is the name used in the path. >>>>>> >>>>>> Mike >>>>>> >>>>>> On May 20, 2014, at 9:30 PM, David DeHaven wrote: >>>>>> >>>>>>> JBS Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043340 >>>>>>> >>>>>>> Summary: >>>>>>> We currently hard code the path to JavaVM.framework to /System/Library/Framworks. This worked when Apple installed header files in those frameworks when the command line tools were installed. Those headers are no longer installed so we need to change our paths to use the Mac OS X SDK path instead. >>>>>>> >>>>>>> Most of the changes here are just adding $(MAC_SDK_PATH) to the JavaVM (and one case of ApplicationServices) framework. If MAC_SDK_PATH is undefined, then it will simply revert to the current behavior of building against the system frameworks. If configure cannot determine the path to the macosx SDK, then it will spit out a warning but otherwise proceed as normal unless it cannot find headers inside JavaVM.framework, then it will fail. >>>>>>> >>>>>>> Changes of note: >>>>>>> - Added MAC_SDK_PATH, set to the absolute path to the macosx SDK as determined by "$(TOOLCHAIN_PATH)/xcodebuild -sdk macosx -version" >>>>>>> - Changed all -F arguments to -F$(MAC_SDK_PATH) >>>>>>> - I had to add -iframework$(MAC_SDK_PATH) to force it to compile and link all frameworks from the same SDK, otherwise great big gobs of deprecation warnings filled the screen. >>>>>>> - XCODEBUILD was added as we need to use the copy of the tool at the location specified by --with-tools-dir if provided, otherwise we would end up with the completely wrong path. If it's not found in the tool path then it uses the default /usr/bin/xcodebuild (if that's not there then the system is not configured properly...) >>>>>>> - Removed JavaVM.framework from the header search path (and changed MacosxDebuggerLocal.m accordingly) in hotspot, we shouldn't be using those headers >>>>>>> - I made not being able to find JavaVM.framework a fatal error in configure, since we can't build without those headers >>>>>>> >>>>>>> Tested on 10.8 with Xcode 5.1 and Xcode 4.6.3 and on a clean 10.9 system with Xcode 5.1 against jdk9/hs. I will submit a JPRT sanity run shortly. >>>>>>> >>>>>>> Patches: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/top >>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/hotspot >>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v0/jdk >>>>>>> >>>>>>> -DrD- >>>>>>> >> > From david.dehaven at oracle.com Thu May 22 16:26:24 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 22 May 2014 09:26:24 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> Message-ID: <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> >> That will cause the -isysroot argument to be invalid. I can either make an undefined MACOSX_SDK_PATH a hard error (in configure) > > Earlier failure is better. > >> or I can wrap all uses of -isysroot/-iframework with ifneq blocks. > > Yuck. Agreed. I already don't like that I have to use -isysroot/-iframework, but it's what we have to live with until we're free of the JavaVM.framework dependency. -DrD- From philip.race at oracle.com Thu May 22 20:02:04 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 22 May 2014 13:02:04 -0700 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <20140522004931.GG3957@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> Message-ID: <537E57BC.2010400@oracle.com> BTW .. I just realised I haven't seen a bug ID in this thread. Does one already exist ? -phil. On 5/21/14 5:49 PM, Omair Majid wrote: > * Andrew Hughes [2014-05-21 20:23]: >> ----- Original Message ----- >>> * Andrew Hughes [2014-05-21 12:22]: >>>> I'm not keen on the hardcoding of '-ljpeg' >>>> >>>> + LIBJPEG_LIBS := -ljpeg >>> There's no pkg-config files for it. Any suggestions on how to get >>> something generic? >>> >> I know there isn't at present. I still think it's better to be consistent >> and set the values in configure, even if at present they have to be hardcoded >> defaults. > Would you mind if I did this as a separate patch? I will need to fix > other libraries too (libzip, and libgif). > >> The make documentation is a little unclear here, and makes it sound like it >> will always be set if := or = is used. > Indeed, it is unclear. But I discovered through trial and error that > given a Makefile like: > > FOO=-v > all: > gcc ${FOO} > > these two forms are different: > > $ FOO=bar make > > $ make FOO=bar > > The first one sets the environment variable FOO, and the Makefile > overrides it (it runs `gcc -v`). The second passes a command line > argument that overrides the value in the Makefile (it runs `gcc foo`). > > Thanks, > Omair > From gnu.andrew at redhat.com Thu May 22 20:10:30 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 22 May 2014 16:10:30 -0400 (EDT) Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <537DBD0C.2010809@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> <537DBD0C.2010809@oracle.com> Message-ID: <1569662464.10171034.1400789430009.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On 2014-05-22 02:49, Omair Majid wrote: > > * Andrew Hughes [2014-05-21 20:23]: > >> ----- Original Message ----- > >>> * Andrew Hughes [2014-05-21 12:22]: > >>>> I'm not keen on the hardcoding of '-ljpeg' > >>>> > >>>> + LIBJPEG_LIBS := -ljpeg > >>> There's no pkg-config files for it. Any suggestions on how to get > >>> something generic? > >>> > >> I know there isn't at present. I still think it's better to be consistent > >> and set the values in configure, even if at present they have to be > >> hardcoded > >> defaults. > > Would you mind if I did this as a separate patch? I will need to fix > > other libraries too (libzip, and libgif). > > Ok, I thought the other ones were already in this form. In that case, leave it to me and I'll go through them as a whole. I want to look at the option formatting anyway. > >> The make documentation is a little unclear here, and makes it sound like > >> it > >> will always be set if := or = is used. > > Indeed, it is unclear. But I discovered through trial and error that > > given a Makefile like: > > > > FOO=-v > > all: > > gcc ${FOO} > > > > these two forms are different: > > > > $ FOO=bar make > > > > $ make FOO=bar > > > > The first one sets the environment variable FOO, and the Makefile > > overrides it (it runs `gcc -v`). The second passes a command line > > argument that overrides the value in the Makefile (it runs `gcc foo`). > This is my experience too. There is the "override" keyword that you can > use to not allow command line overrides: > > override FOO=-v > > The above would make both forms behave the same. > Yeah, I was about to mention this. It's described on the next page of the make manual. So I guess := and ?= are only different if you have the variable being set elsewhere in the Makefiles. > /Erik > > Thanks, > > Omair > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From mikael.vidstedt at oracle.com Thu May 22 20:13:30 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 22 May 2014 13:13:30 -0700 Subject: RFR (XS): 8043210: Add _BIG_ENDIAN define on linux/sparc Message-ID: <537E5A6A.1040208@oracle.com> Please review the following change, destined for jdk7u-dev. The zip implementation in unpack200 depends on _BIG_ENDIAN being defined on big endian platforms, and the define is missing on the linux/sparc platform(s). Note that in the new build system (jdk8+) the relevant logic was rewritten, so the problem does not exists there. Bug: https://bugs.openjdk.java.net/browse/JDK-8043210 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8043210/webrev.00/webrev/ Thanks, Mikael From omajid at redhat.com Thu May 22 20:28:08 2014 From: omajid at redhat.com (Omair Majid) Date: Thu, 22 May 2014 16:28:08 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <537E57BC.2010400@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com> Message-ID: <20140522202808.GJ2825@redhat.com> * Phil Race [2014-05-22 16:02]: > BTW .. I just realised I haven't seen a bug ID in this thread. > Does one already exist ? No. I was going to create one before I push. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kumar.x.srinivasan at oracle.com Thu May 22 20:31:52 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 22 May 2014 13:31:52 -0700 Subject: RFR (XS): 8043210: Add _BIG_ENDIAN define on linux/sparc In-Reply-To: <537E5A6A.1040208@oracle.com> References: <537E5A6A.1040208@oracle.com> Message-ID: <537E5EB8.7020505@oracle.com> Looks good but IIRC PPC also needs this. Kumar On 5/22/2014 1:13 PM, Mikael Vidstedt wrote: > > Please review the following change, destined for jdk7u-dev. The zip > implementation in unpack200 depends on _BIG_ENDIAN being defined on > big endian platforms, and the define is missing on the linux/sparc > platform(s). > > Note that in the new build system (jdk8+) the relevant logic was > rewritten, so the problem does not exists there. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043210 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8043210/webrev.00/webrev/ > > Thanks, > Mikael > From mikael.vidstedt at oracle.com Thu May 22 20:38:42 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 22 May 2014 13:38:42 -0700 Subject: RFR (XS): 8043210: Add _BIG_ENDIAN define on linux/sparc In-Reply-To: <537E5EB8.7020505@oracle.com> References: <537E5A6A.1040208@oracle.com> <537E5EB8.7020505@oracle.com> Message-ID: <537E6052.6050904@oracle.com> AFAICT PPC already has the define: 199 CFLAGS_REQUIRED_ppc += -fsigned-char -D_BIG_ENDIAN Cheers, Mikael On 2014-05-22 13:31, Kumar Srinivasan wrote: > Looks good but IIRC PPC also needs this. > > Kumar > > On 5/22/2014 1:13 PM, Mikael Vidstedt wrote: >> >> Please review the following change, destined for jdk7u-dev. The zip >> implementation in unpack200 depends on _BIG_ENDIAN being defined on >> big endian platforms, and the define is missing on the linux/sparc >> platform(s). >> >> Note that in the new build system (jdk8+) the relevant logic was >> rewritten, so the problem does not exists there. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043210 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8043210/webrev.00/webrev/ >> >> Thanks, >> Mikael >> > From anthony.petrov at oracle.com Thu May 22 20:48:14 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 23 May 2014 00:48:14 +0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <20140522202808.GJ2825@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com> <20140522202808.GJ2825@redhat.com> Message-ID: <537E628E.7070900@oracle.com> I think that it would be useful to have a bug id prior to sending a review request, so that a review thread for the bug can be easily found in the mailing archive. In the future, please do file a bug first and put its id in the subject line of your review requests. -- best regards, Anthony On 5/23/2014 12:28 AM, Omair Majid wrote: > * Phil Race [2014-05-22 16:02]: >> BTW .. I just realised I haven't seen a bug ID in this thread. >> Does one already exist ? > > No. I was going to create one before I push. > > Thanks, > Omair > From omajid at redhat.com Thu May 22 21:01:28 2014 From: omajid at redhat.com (Omair Majid) Date: Thu, 22 May 2014 17:01:28 -0400 Subject: RFR: 8043805: Allow using a system-installed libjpeg In-Reply-To: <537E628E.7070900@oracle.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com> <20140522202808.GJ2825@redhat.com> <537E628E.7070900@oracle.com> Message-ID: <20140522210127.GK2825@redhat.com> * Anthony Petrov [2014-05-22 16:48]: > I think that it would be useful to have a bug id prior to sending a review > request, so that a review thread for the bug can be easily found in the > mailing archive. In the future, please do file a bug first and put its id in > the subject line of your review requests. Apologies. I have filed https://bugs.openjdk.java.net/browse/JDK-8043805 and updated the subject of the thread. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From anthony.petrov at oracle.com Thu May 22 21:27:56 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Fri, 23 May 2014 01:27:56 +0400 Subject: RFR: 8043805: Allow using a system-installed libjpeg In-Reply-To: <20140522210127.GK2825@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> <537E57BC.2010400@oracle.com> <20140522202808.GJ2825@redhat.com> <537E628E.7070900@oracle.com> <20140522210127.GK2825@redhat.com> Message-ID: <537E6BDC.3020301@oracle.com> Thanks, Omair. -- best regards, Anthony On 5/23/2014 1:01 AM, Omair Majid wrote: > * Anthony Petrov [2014-05-22 16:48]: >> I think that it would be useful to have a bug id prior to sending a review >> request, so that a review thread for the bug can be easily found in the >> mailing archive. In the future, please do file a bug first and put its id in >> the subject line of your review requests. > > Apologies. > > I have filed https://bugs.openjdk.java.net/browse/JDK-8043805 and > updated the subject of the thread. > > Thanks, > Omair > From david.holmes at oracle.com Fri May 23 02:37:42 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 May 2014 12:37:42 +1000 Subject: RFR (XS): 8043210: Add _BIG_ENDIAN define on linux/sparc In-Reply-To: <537E5A6A.1040208@oracle.com> References: <537E5A6A.1040208@oracle.com> Message-ID: <537EB476.5010903@oracle.com> Looks good. David On 23/05/2014 6:13 AM, Mikael Vidstedt wrote: > > Please review the following change, destined for jdk7u-dev. The zip > implementation in unpack200 depends on _BIG_ENDIAN being defined on big > endian platforms, and the define is missing on the linux/sparc platform(s). > > Note that in the new build system (jdk8+) the relevant logic was > rewritten, so the problem does not exists there. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8043210 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8043210/webrev.00/webrev/ > > Thanks, > Mikael > From david.dehaven at oracle.com Fri May 23 06:16:55 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 22 May 2014 23:16:55 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> Message-ID: Build systems take such a long time work on... I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... I also added two configure args: --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 [macosx] --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] Please note that this version is against jdk9-dev with the following patches imported from other forests: hotspot: JDK-8043164 (jdk9/hs) jdk: JDK-8042440 (jdk9/client) JDK-8043646 (jdk9/client) JDK-8003900 (jdk9/client) Updated patches: http://cr.openjdk.java.net/~ddehaven/8043340/v1/base http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk -DrD- From erik.joelsson at oracle.com Fri May 23 09:01:40 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 May 2014 11:01:40 +0200 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> Message-ID: <537F0E74.7040709@oracle.com> Hello David, I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? /Erik On 2014-05-23 08:16, David DeHaven wrote: > Build systems take such a long time work on... > > I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... > > I also added two configure args: > --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 > [macosx] > --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] > Please note that this version is against jdk9-dev with the following patches imported from other forests: > hotspot: > JDK-8043164 (jdk9/hs) > > jdk: > JDK-8042440 (jdk9/client) > JDK-8043646 (jdk9/client) > JDK-8003900 (jdk9/client) > > > Updated patches: > http://cr.openjdk.java.net/~ddehaven/8043340/v1/base > http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot > http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk > > -DrD- > From erik.joelsson at oracle.com Fri May 23 10:31:42 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 23 May 2014 12:31:42 +0200 Subject: RFR: JDK-8043160: JDK 9 Build failure in accessbridge Message-ID: <537F238E.8070802@oracle.com> Hello, This patch attempts to fix a build problem in accessbridge. Two compile jobs are both trying to create the same header file. The fix is to separate the output directories of these jobs so that they do not interfere with each other. Bug: https://bugs.openjdk.java.net/browse/JDK-8043160 Webrev: http://cr.openjdk.java.net/~erikj/8043160/webrev.jdk.01/ /Erik From omajid at redhat.com Fri May 23 15:12:53 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 23 May 2014 11:12:53 -0400 Subject: [OpenJDK 2D-Dev] RFR: Allow using the system libjpeg In-Reply-To: <1569662464.10171034.1400789430009.JavaMail.zimbra@redhat.com> References: <20140517004529.GD4370@redhat.com> <537A509E.2090504@oracle.com> <20140520171120.GD2672@redhat.com> <113374082.9431548.1400689299752.JavaMail.zimbra@redhat.com> <20140521205934.GE3957@redhat.com> <1195011350.9563091.1400718203798.JavaMail.zimbra@redhat.com> <20140522004931.GG3957@redhat.com> <537DBD0C.2010809@oracle.com> <1569662464.10171034.1400789430009.JavaMail.zimbra@redhat.com> Message-ID: <20140523151252.GD2799@redhat.com> * Andrew Hughes [2014-05-22 16:10]: > ----- Original Message ----- > > On 2014-05-22 02:49, Omair Majid wrote: > > > Would you mind if I did this as a separate patch? I will need to fix > > > other libraries too (libzip, and libgif). > > > > > Ok, I thought the other ones were already in this form. In that case, leave it > to me and I'll go through them as a whole. Thanks. The relevant bits are in spec.gmk.in: 565 USE_EXTERNAL_LIBJPEG:=@USE_EXTERNAL_LIBJPEG@ 566 USE_EXTERNAL_LIBGIF:=@USE_EXTERNAL_LIBGIF@ 567 USE_EXTERNAL_LIBZ:=@USE_EXTERNAL_LIBZ@ Further down in the file, other libraries have both CFLAGS and LIBS defined: 655 USE_EXTERNAL_LCMS:=@USE_EXTERNAL_LCMS@ 656 LCMS_CFLAGS:=@LCMS_CFLAGS@ 657 LCMS_LIBS:=@LCMS_LIBS@ 658 659 USE_EXTERNAL_LIBPNG:=@USE_EXTERNAL_LIBPNG@ 660 PNG_LIBS:=@PNG_LIBS@ 661 PNG_CFLAGS:=@PNG_CFLAGS@ Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.dehaven at oracle.com Fri May 23 16:04:26 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 23 May 2014 09:04:26 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <537F0E74.7040709@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> Message-ID: <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. We'll do something like: # assuming SYSROOT="$with_sysroot" already if test "x$OPENJDK_TARGET_OS" = xmacosx; then if test ! -d "$SYSROOT"; then # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` if test ! -d "$SYSROOT"; then AC_MSG_ERROR([SYSROOT does not point to a valid path]) fi fi SDKROOT=$SYSROOT AC_SUBST(SDKROOT) fi This will eliminate any added configure arguments. (14 hours of build system hacking makes for a very muddled mind...) -DrD- > Hello David, > > I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? > > /Erik > > On 2014-05-23 08:16, David DeHaven wrote: >> Build systems take such a long time work on... >> >> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >> >> I also added two configure args: >> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >> [macosx] >> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] > >> Please note that this version is against jdk9-dev with the following patches imported from other forests: >> hotspot: >> JDK-8043164 (jdk9/hs) >> >> jdk: >> JDK-8042440 (jdk9/client) >> JDK-8043646 (jdk9/client) >> JDK-8003900 (jdk9/client) >> >> >> Updated patches: >> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >> >> -DrD- >> > From mikael.vidstedt at oracle.com Fri May 23 16:14:24 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 23 May 2014 09:14:24 -0700 Subject: RFR (XS): 8043210: Add _BIG_ENDIAN define on linux/sparc In-Reply-To: <537EB476.5010903@oracle.com> References: <537E5A6A.1040208@oracle.com> <537EB476.5010903@oracle.com> Message-ID: <537F73E0.4000003@oracle.com> Kumar, David - thanks for the reviews! Cheers, Mikael On 2014-05-22 19:37, David Holmes wrote: > Looks good. > > David > > On 23/05/2014 6:13 AM, Mikael Vidstedt wrote: >> >> Please review the following change, destined for jdk7u-dev. The zip >> implementation in unpack200 depends on _BIG_ENDIAN being defined on big >> endian platforms, and the define is missing on the linux/sparc >> platform(s). >> >> Note that in the new build system (jdk8+) the relevant logic was >> rewritten, so the problem does not exists there. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8043210 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8043210/webrev.00/webrev/ >> >> Thanks, >> Mikael >> From david.dehaven at oracle.com Fri May 23 16:34:15 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 23 May 2014 09:34:15 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> Message-ID: <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> Nobody should be using this any more, can I nuke it? BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support) That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. -DrD- > > Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) > > MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. > > We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. > > > We'll do something like: > > # assuming SYSROOT="$with_sysroot" already > if test "x$OPENJDK_TARGET_OS" = xmacosx; then > if test ! -d "$SYSROOT"; then > # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK > SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` > if test ! -d "$SYSROOT"; then > AC_MSG_ERROR([SYSROOT does not point to a valid path]) > fi > fi > SDKROOT=$SYSROOT > AC_SUBST(SDKROOT) > fi > > This will eliminate any added configure arguments. > > (14 hours of build system hacking makes for a very muddled mind...) > > -DrD- > > >> Hello David, >> >> I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? >> >> /Erik >> >> On 2014-05-23 08:16, David DeHaven wrote: >>> Build systems take such a long time work on... >>> >>> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >>> >>> I also added two configure args: >>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >>> [macosx] >>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >> >>> Please note that this version is against jdk9-dev with the following patches imported from other forests: >>> hotspot: >>> JDK-8043164 (jdk9/hs) >>> >>> jdk: >>> JDK-8042440 (jdk9/client) >>> JDK-8043646 (jdk9/client) >>> JDK-8003900 (jdk9/client) >>> >>> >>> Updated patches: >>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>> >>> -DrD- >>> >> > From david.dehaven at oracle.com Fri May 23 16:38:16 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 23 May 2014 09:38:16 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> Message-ID: I'm combining this fix with another as it was starting to make my head split trying to keep the two separate, they're just too closely related. I'll start another review thread for the combined patches. -DrD- > > Nobody should be using this any more, can I nuke it? > > BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support) > > That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. > > -DrD- > >> >> Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) >> >> MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. >> >> We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. >> >> >> We'll do something like: >> >> # assuming SYSROOT="$with_sysroot" already >> if test "x$OPENJDK_TARGET_OS" = xmacosx; then >> if test ! -d "$SYSROOT"; then >> # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK >> SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` >> if test ! -d "$SYSROOT"; then >> AC_MSG_ERROR([SYSROOT does not point to a valid path]) >> fi >> fi >> SDKROOT=$SYSROOT >> AC_SUBST(SDKROOT) >> fi >> >> This will eliminate any added configure arguments. >> >> (14 hours of build system hacking makes for a very muddled mind...) >> >> -DrD- >> >> >>> Hello David, >>> >>> I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? >>> >>> /Erik >>> >>> On 2014-05-23 08:16, David DeHaven wrote: >>>> Build systems take such a long time work on... >>>> >>>> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >>>> >>>> I also added two configure args: >>>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >>>> [macosx] >>>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >>> >>>> Please note that this version is against jdk9-dev with the following patches imported from other forests: >>>> hotspot: >>>> JDK-8043164 (jdk9/hs) >>>> >>>> jdk: >>>> JDK-8042440 (jdk9/client) >>>> JDK-8043646 (jdk9/client) >>>> JDK-8003900 (jdk9/client) >>>> >>>> >>>> Updated patches: >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>>> >>>> -DrD- >>>> >>> >> > From erik.joelsson at oracle.com Mon May 26 09:22:35 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 May 2014 11:22:35 +0200 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> Message-ID: <538307DB.7040702@oracle.com> It looks to me like that we can remove the option in jdk9 since it was deprecated in 8. It's a noop anyway though so shouldn't interfere with your work. I'm not sure if giving --with-sysroot an optional special format for macosx is the right way to go. It looks cleaner from one way, but also increases confusion I think. I prefer a special parameter, which helps setting sysroot as suggested. If you need a synonym for SYSROOT in macosx, that seems fine to me. /Erik On 2014-05-23 18:38, David DeHaven wrote: > I'm combining this fix with another as it was starting to make my head split trying to keep the two separate, they're just too closely related. I'll start another review thread for the combined patches. > > -DrD- > >> Nobody should be using this any more, can I nuke it? >> >> BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support) >> >> That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. >> >> -DrD- >> >>> Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) >>> >>> MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. >>> >>> We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. >>> >>> >>> We'll do something like: >>> >>> # assuming SYSROOT="$with_sysroot" already >>> if test "x$OPENJDK_TARGET_OS" = xmacosx; then >>> if test ! -d "$SYSROOT"; then >>> # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK >>> SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` >>> if test ! -d "$SYSROOT"; then >>> AC_MSG_ERROR([SYSROOT does not point to a valid path]) >>> fi >>> fi >>> SDKROOT=$SYSROOT >>> AC_SUBST(SDKROOT) >>> fi >>> >>> This will eliminate any added configure arguments. >>> >>> (14 hours of build system hacking makes for a very muddled mind...) >>> >>> -DrD- >>> >>> >>>> Hello David, >>>> >>>> I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? >>>> >>>> /Erik >>>> >>>> On 2014-05-23 08:16, David DeHaven wrote: >>>>> Build systems take such a long time work on... >>>>> >>>>> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >>>>> >>>>> I also added two configure args: >>>>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >>>>> [macosx] >>>>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >>>>> Please note that this version is against jdk9-dev with the following patches imported from other forests: >>>>> hotspot: >>>>> JDK-8043164 (jdk9/hs) >>>>> >>>>> jdk: >>>>> JDK-8042440 (jdk9/client) >>>>> JDK-8043646 (jdk9/client) >>>>> JDK-8003900 (jdk9/client) >>>>> >>>>> >>>>> Updated patches: >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>>>> >>>>> -DrD- >>>>> From david.dehaven at oracle.com Tue May 27 16:29:56 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 27 May 2014 09:29:56 -0700 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <538307DB.7040702@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> Message-ID: <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> I tend to agree. How about --with-sdk-name=? SDKROOT implies a path, as would something like --with-sdk (and I could see that being confusing for someone building on Windows. I got successful builds on Friday. I'll make the above changes and post another iteration for review. -DrD- > It looks to me like that we can remove the option in jdk9 since it was deprecated in 8. It's a noop anyway though so shouldn't interfere with your work. > > I'm not sure if giving --with-sysroot an optional special format for macosx is the right way to go. It looks cleaner from one way, but also increases confusion I think. I prefer a special parameter, which helps setting sysroot as suggested. > > If you need a synonym for SYSROOT in macosx, that seems fine to me. > > /Erik > > On 2014-05-23 18:38, David DeHaven wrote: >> I'm combining this fix with another as it was starting to make my head split trying to keep the two separate, they're just too closely related. I'll start another review thread for the combined patches. >> >> -DrD- >> >>> Nobody should be using this any more, can I nuke it? >>> >>> BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support) >>> >>> That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. >>> >>> -DrD- >>> >>>> Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) >>>> >>>> MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. >>>> >>>> We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. >>>> >>>> >>>> We'll do something like: >>>> >>>> # assuming SYSROOT="$with_sysroot" already >>>> if test "x$OPENJDK_TARGET_OS" = xmacosx; then >>>> if test ! -d "$SYSROOT"; then >>>> # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK >>>> SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` >>>> if test ! -d "$SYSROOT"; then >>>> AC_MSG_ERROR([SYSROOT does not point to a valid path]) >>>> fi >>>> fi >>>> SDKROOT=$SYSROOT >>>> AC_SUBST(SDKROOT) >>>> fi >>>> >>>> This will eliminate any added configure arguments. >>>> >>>> (14 hours of build system hacking makes for a very muddled mind...) >>>> >>>> -DrD- >>>> >>>> >>>>> Hello David, >>>>> >>>>> I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? >>>>> >>>>> /Erik >>>>> >>>>> On 2014-05-23 08:16, David DeHaven wrote: >>>>>> Build systems take such a long time work on... >>>>>> >>>>>> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >>>>>> >>>>>> I also added two configure args: >>>>>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >>>>>> [macosx] >>>>>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >>>>>> Please note that this version is against jdk9-dev with the following patches imported from other forests: >>>>>> hotspot: >>>>>> JDK-8043164 (jdk9/hs) >>>>>> >>>>>> jdk: >>>>>> JDK-8042440 (jdk9/client) >>>>>> JDK-8043646 (jdk9/client) >>>>>> JDK-8003900 (jdk9/client) >>>>>> >>>>>> >>>>>> Updated patches: >>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>>>>> >>>>>> -DrD- >>>>>> > From erik.joelsson at oracle.com Wed May 28 08:41:07 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 May 2014 10:41:07 +0200 Subject: RFR: [9] 8043340: [macosx] Fix hard-wired paths to JavaVM.framework In-Reply-To: <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> Message-ID: <5385A123.3010303@oracle.com> I think --with-sdk-name sounds good. Just make sure to document it very clearly to minimize confusion between --with-sysroot --with-devkit and --with-tools-path. We are gathering quite a few related options here. If this new option is used to set sysroot, then it should probably move closer to the sysroot setting, which is setup in BASIC_SETUP_DEVKIT. I realize you then need to find xcodebuild there already, using the TOOLCHAIN_PATH, but I think that's ok, since that tools is used specifically for finding a sysroot on mac. Overall, I like where this is going. /Erik On 2014-05-27 18:29, David DeHaven wrote: > I tend to agree. How about --with-sdk-name=? SDKROOT implies a path, as would something like --with-sdk (and I could see that being confusing for someone building on Windows. > > I got successful builds on Friday. I'll make the above changes and post another iteration for review. > > -DrD- > >> It looks to me like that we can remove the option in jdk9 since it was deprecated in 8. It's a noop anyway though so shouldn't interfere with your work. >> >> I'm not sure if giving --with-sysroot an optional special format for macosx is the right way to go. It looks cleaner from one way, but also increases confusion I think. I prefer a special parameter, which helps setting sysroot as suggested. >> >> If you need a synonym for SYSROOT in macosx, that seems fine to me. >> >> /Erik >> >> On 2014-05-23 18:38, David DeHaven wrote: >>> I'm combining this fix with another as it was starting to make my head split trying to keep the two separate, they're just too closely related. I'll start another review thread for the combined patches. >>> >>> -DrD- >>> >>>> Nobody should be using this any more, can I nuke it? >>>> >>>> BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support) >>>> >>>> That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. >>>> >>>> -DrD- >>>> >>>>> Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) >>>>> >>>>> MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. >>>>> >>>>> We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. >>>>> >>>>> >>>>> We'll do something like: >>>>> >>>>> # assuming SYSROOT="$with_sysroot" already >>>>> if test "x$OPENJDK_TARGET_OS" = xmacosx; then >>>>> if test ! -d "$SYSROOT"; then >>>>> # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK >>>>> SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` >>>>> if test ! -d "$SYSROOT"; then >>>>> AC_MSG_ERROR([SYSROOT does not point to a valid path]) >>>>> fi >>>>> fi >>>>> SDKROOT=$SYSROOT >>>>> AC_SUBST(SDKROOT) >>>>> fi >>>>> >>>>> This will eliminate any added configure arguments. >>>>> >>>>> (14 hours of build system hacking makes for a very muddled mind...) >>>>> >>>>> -DrD- >>>>> >>>>> >>>>>> Hello David, >>>>>> >>>>>> I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2014-05-23 08:16, David DeHaven wrote: >>>>>>> Build systems take such a long time work on... >>>>>>> >>>>>>> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >>>>>>> >>>>>>> I also added two configure args: >>>>>>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >>>>>>> [macosx] >>>>>>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >>>>>>> Please note that this version is against jdk9-dev with the following patches imported from other forests: >>>>>>> hotspot: >>>>>>> JDK-8043164 (jdk9/hs) >>>>>>> >>>>>>> jdk: >>>>>>> JDK-8042440 (jdk9/client) >>>>>>> JDK-8043646 (jdk9/client) >>>>>>> JDK-8003900 (jdk9/client) >>>>>>> >>>>>>> >>>>>>> Updated patches: >>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>>>>>> >>>>>>> -DrD- >>>>>>> From weijun.wang at oracle.com Wed May 28 10:51:23 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 28 May 2014 18:51:23 +0800 Subject: xcodebuild necessary on Mac? Message-ID: I just installed a brand new Mavericks and go straight to 'bash configure' for jdk9/dev. A dialog pops out asking me to choose between installing Xcode and downloading command line tools. I choose the latter and after they are installed I run configure again, and it shows Failed to determine Xcode version. Looking into common/autoconf/toolchain.m4 and it's running xcodebuild to find out the version. Since this is Mavericks I think it should be 5. So I write my own xcodebuild that shows itself as Xcode 5 and configure passed. And the build runs fine (after installing XQuartz). So why is xcodebuild necessary? What must I install Xcode to build openjdk? I can see 'gcc --version' showing 'LLVM' and '5.1' words also. Thanks Max From david.dehaven at oracle.com Wed May 28 15:43:57 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 28 May 2014 08:43:57 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: References: Message-ID: > I just installed a brand new Mavericks and go straight to 'bash configure' for jdk9/dev. A dialog pops out asking me to choose between installing Xcode and downloading command line tools. I choose the latter and after they are installed I run configure again, and it shows > > Failed to determine Xcode version. This looks like a bug. How did you run configure? > Looking into common/autoconf/toolchain.m4 and it's running xcodebuild to find out the version. Since this is Mavericks I think it should be 5. So I write my own xcodebuild that shows itself as Xcode 5 and configure passed. > > And the build runs fine (after installing XQuartz). You no longer need XQuartz: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/56024e323104 > So why is xcodebuild necessary? What must I install Xcode to build openjdk? I can see 'gcc --version' showing 'LLVM' and '5.1' words also. xcodebuild is used to find components that are necessary to build. GCC is no longer installed with Xcode, they switched to clang, which is why we need to determine what version of Xcode is installed. -DrD- From omajid at redhat.com Wed May 28 23:33:19 2014 From: omajid at redhat.com (Omair Majid) Date: Wed, 28 May 2014 19:33:19 -0400 Subject: RFR: 8044235: src.zip should include all sources Message-ID: <20140528233319.GB8191@redhat.com> Hi, Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8044235-src-zip-include-all/00/ The src.zip file produced in an OpenJDK build contains the code for a subset of the Java class library. Developers who wish to debug their program and step into the source of a class that's part of the Java class library are often disappointed when they find that their IDE can not do that because src.zip does not include the source for the class. The webrev basically stops the filtering and includes all sources in src.zip. I noticed a glitch unrelated to the patch: somehow the src.zip ends up containing the source for launcher, which is in C, too. But this happens without the patch too, so it's not a regression. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From weijun.wang at oracle.com Thu May 29 02:15:51 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 29 May 2014 10:15:51 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: References: Message-ID: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> On May 28, 2014, at 23:43, David DeHaven wrote: > >> I just installed a brand new Mavericks and go straight to 'bash configure' for jdk9/dev. A dialog pops out asking me to choose between installing Xcode and downloading command line tools. I choose the latter and after they are installed I run configure again, and it shows >> >> Failed to determine Xcode version. > > This looks like a bug. How did you run configure? Just "bash configure --with-boot-jdk=/myjdk". Do you mean xcodebuild should not be called? > > >> Looking into common/autoconf/toolchain.m4 and it's running xcodebuild to find out the version. Since this is Mavericks I think it should be 5. So I write my own xcodebuild that shows itself as Xcode 5 and configure passed. >> >> And the build runs fine (after installing XQuartz). > > You no longer need XQuartz: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/56024e323104 Oh, guess my repo is not synced. > > >> So why is xcodebuild necessary? What must I install Xcode to build openjdk? I can see 'gcc --version' showing 'LLVM' and '5.1' words also. > > xcodebuild is used to find components that are necessary to build. GCC is no longer installed with Xcode, they switched to clang, which is why we need to determine what version of Xcode is installed. IIRC, gcc is just a wrapper for any compiler. At least it's on my system and 'gcc -version' shows LLVM. On the other hand, it looks like xcodebuild is not always installed. Thanks Max > > -DrD- > From henry.jen at oracle.com Thu May 29 04:19:30 2014 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 28 May 2014 21:19:30 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> Message-ID: <5386B552.7060605@oracle.com> 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? Cheers, Henry From weijun.wang at oracle.com Thu May 29 04:32:23 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 29 May 2014 12:32:23 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: <5386B552.7060605@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> Message-ID: <81187D1C-26B0-40A3-A3F4-23BB24D99906@oracle.com> 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 out where is your xcodebuild located and what does it return with xcodebuild -version? It is a clean install of Mavericks before I run the first configure, so I am OK with the dialog. The dialog offers two options: one is install Xcode, one is download and install compilers. (I cannot remember the exact words). I chose the latter because I don't need an IDE. It seems this option installs the compiler and tools like make but has not included xcodebuild. This is why I see the error message in my second configure run. As I said, I created my own fake xcodebuild to tell the configure (3rd run) it's Xcode 5, configure happily accepts it this time, and then the build goes fine. That seems to show xcodebuild is not necessary and Xcode is not necessary. Thanks Max > > Cheers, > Henry From david.holmes at oracle.com Thu May 29 10:52:55 2014 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 May 2014 20:52:55 +1000 Subject: RFR: 8044235: src.zip should include all sources In-Reply-To: <20140528233319.GB8191@redhat.com> References: <20140528233319.GB8191@redhat.com> Message-ID: <53871187.7060004@oracle.com> Hi Omair, This seems harmless for OPENJDK builds. David On 29/05/2014 9:33 AM, Omair Majid wrote: > Hi, > > Webrev: > http://cr.openjdk.java.net/~omajid/webrevs/8044235-src-zip-include-all/00/ > > The src.zip file produced in an OpenJDK build contains the code for a > subset of the Java class library. Developers who wish to debug their > program and step into the source of a class that's part of the Java > class library are often disappointed when they find that their IDE can > not do that because src.zip does not include the source for the class. > > The webrev basically stops the filtering and includes all sources in > src.zip. > > I noticed a glitch unrelated to the patch: somehow the src.zip ends up > containing the source for launcher, which is in C, too. But this happens > without the patch too, so it's not a regression. > > Thanks, > Omair > From gnu.andrew at redhat.com Thu May 29 14:59:01 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 29 May 2014 10:59:01 -0400 (EDT) Subject: RFR: 8044235: src.zip should include all sources In-Reply-To: <53871187.7060004@oracle.com> References: <20140528233319.GB8191@redhat.com> <53871187.7060004@oracle.com> Message-ID: <580000066.13760571.1401375541776.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Omair, > > This seems harmless for OPENJDK builds. > > David > > On 29/05/2014 9:33 AM, Omair Majid wrote: > > Hi, > > > > Webrev: > > http://cr.openjdk.java.net/~omajid/webrevs/8044235-src-zip-include-all/00/ > > > > The src.zip file produced in an OpenJDK build contains the code for a > > subset of the Java class library. Developers who wish to debug their > > program and step into the source of a class that's part of the Java > > class library are often disappointed when they find that their IDE can > > not do that because src.zip does not include the source for the class. > > > > The webrev basically stops the filtering and includes all sources in > > src.zip. > > > > I noticed a glitch unrelated to the patch: somehow the src.zip ends up > > containing the source for launcher, which is in C, too. But this happens > > without the patch too, so it's not a regression. > > > > Thanks, > > Omair > > > Looks good to me too. There's no need to exclude source files from the open build. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From henry.jen at oracle.com Thu May 29 15:49:41 2014 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 29 May 2014 08:49:41 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <81187D1C-26B0-40A3-A3F4-23BB24D99906@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <81187D1C-26B0-40A3-A3F4-23BB24D99906@oracle.com> Message-ID: <53875715.6060307@oracle.com> 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 out where is your xcodebuild located and what does it return with xcodebuild -version? > > It is a clean install of Mavericks before I run the first configure, so I am OK with the dialog. The dialog offers two options: one is install Xcode, one is download and install compilers. (I cannot remember the exact words). I chose the latter because I don't need an IDE. It seems this option installs the compiler and tools like make but has not included xcodebuild. This is why I see the error message in my second configure run. > > As I said, I created my own fake xcodebuild to tell the configure (3rd run) it's Xcode 5, configure happily accepts it this time, and then the build goes fine. That seems to show xcodebuild is not necessary and Xcode is not necessary. > Sorry it was not clear, what I meant is that xcodebuild call is what triggered the installation dialog, meaning there was a placeholder for xcodebuild. What I would like to confirm is after you install command line tools, is there a xcodebuild somewhere? From your situation, I guess the answer is NO. Cheers, Henry From david.dehaven at oracle.com Thu May 29 15:54:58 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 29 May 2014 08:54:58 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <81187D1C-26B0-40A3-A3F4-23BB24D99906@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <81187D1C-26B0-40A3-A3F4-23BB24D99906@oracle.com> Message-ID: >>> 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? > > It is a clean install of Mavericks before I run the first configure, so I am OK with the dialog. The dialog offers two options: one is install Xcode, one is download and install compilers. (I cannot remember the exact words). I chose the latter because I don't need an IDE. It seems this option installs the compiler and tools like make but has not included xcodebuild. This is why I see the error message in my second configure run. > > As I said, I created my own fake xcodebuild to tell the configure (3rd run) it's Xcode 5, configure happily accepts it this time, and then the build goes fine. That seems to show xcodebuild is not necessary and Xcode is not necessary. That won't be the case when I get my changes for JDK-8043340 pushed, it will require xcodebuild. We list Xcode as a build requirement so it needs to be installed, for 9 this (eventually) will be bumped to Xcode 5. -DrD- From david.dehaven at oracle.com Thu May 29 15:56:47 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 29 May 2014 08:56:47 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <5386B552.7060605@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> Message-ID: >> 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? Apple installs stub binaries in /usr/bin, this exec's the real xcodebuild from the currently selected version of Xcode. If no copy of Xcode is installed it triggers the "You need to install Xcode" user experience. Apparently there's an option to only install the command line tools, I didn't know about that. I'm curious if only installing the CL tools also installs at least one OS X SDK. If it doesn't then it's not terribly useful, except for maybe porting/building Unix command line tools. -DrD- From mikael.vidstedt at oracle.com Thu May 29 20:29:34 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 29 May 2014 13:29:34 -0700 Subject: RFR(S): 8044363: Remove special build options for unpack200 executable Message-ID: <538798AE.10807@oracle.com> Please review the below fix which removes a couple of build options used when compiling/linking the unpack200 executable - specifically -xregs=no%appl and -xmemalign=4s. Bug: https://bugs.openjdk.java.net/browse/JDK-8044363 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8044363/webrev.00/webrev/ Discussion: The -xregs=no%appl is supposed to be used when compiling system libraries [1], but unpack200 is an executable and so does not fall in that category. The -memalign=4s is supposed to help porting code [2] by having the compiler generate code which does not assume full natural data alignment, but the code in question is clean and does not require this option. Testing: Kumar graciously helped me test the change by manually packing/unpacking across different platforms. I'm taking suggestions on any further testing needed. Thanks, Mikael [1] http://docs.oracle.com/cd/E19205-01/819-5265/bjawv/index.html [2] http://docs.oracle.com/cd/E19205-01/819-5265/bjavc/index.html From kumar.x.srinivasan at oracle.com Thu May 29 20:59:59 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 29 May 2014 13:59:59 -0700 Subject: RFR(S): 8044363: Remove special build options for unpack200 executable In-Reply-To: <538798AE.10807@oracle.com> References: <538798AE.10807@oracle.com> Message-ID: <53879FCF.2050101@oracle.com> Looks good. The JBS bug needs noreg-build Thanks Kumar On 5/29/2014 1:29 PM, Mikael Vidstedt wrote: > > Please review the below fix which removes a couple of build options > used when compiling/linking the unpack200 executable - specifically > -xregs=no%appl and -xmemalign=4s. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8044363 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8044363/webrev.00/webrev/ > > Discussion: > > The -xregs=no%appl is supposed to be used when compiling system > libraries [1], but unpack200 is an executable and so does not fall in > that category. The -memalign=4s is supposed to help porting code [2] > by having the compiler generate code which does not assume full > natural data alignment, but the code in question is clean and does not > require this option. > > Testing: > > Kumar graciously helped me test the change by manually > packing/unpacking across different platforms. I'm taking suggestions > on any further testing needed. > > Thanks, > Mikael > > [1] http://docs.oracle.com/cd/E19205-01/819-5265/bjawv/index.html > [2] http://docs.oracle.com/cd/E19205-01/819-5265/bjavc/index.html From david.dehaven at oracle.com Thu May 29 23:40:37 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 29 May 2014 16:40:37 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <5385A123.3010303@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> Message-ID: <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> This is now a combined fix for: https://bugs.openjdk.java.net/browse/JDK-8043591 https://bugs.openjdk.java.net/browse/JDK-8043340 Since a picture is worth 10,000 words (build systems are 10x as complicated as anything else in life) here's an ASCII flow chart showing the SYSROOT logic I have now: +---------+ | SYSROOT |Y | set? +-------------------+ +----+----+ | |N | | | | | +-++-v--+---+------+ | Y| --with-sdk-name? | | +---+ | | | +----+-------------+ | | |N | | | | | +----v--------+ +---------+ | | | SDKROOT |Y | SYSROOT | | | | set in env? +---> = +-> | | | | SDKROOT | | | +---+---------+ +---------+ | | |N | | +---v---------+ | | | SDKNAME | | | | = | | | | macosx | | | +---+---------+ | | | | | | | | +---v-------------+ | | | Call xcodebuild | | | | to determine | | +---> SYSROOT | | +--------------+--+ | | | +---v------+ | | Validate | | | SYSROOT <-------+ +----------+ So xcodebuild will only be called if a SDK name is provided or neither SYSROOT nor SDKROOT (which must be filesystem paths) are set. The end result is we always have SYSROOT set to some path. If we get to "Validate SYSROOT" and SYSROOT is not set, then we have an error that needs to be addressed (or the user has a misconfigured environment). Only SDKROOT and SYSROOT will be exported. I did have to move XCODEBUILD detection to basics.m4, it was either that or add basically duplicate code to run the right xcodebuild tool. Here's the latest patch set: http://cr.openjdk.java.net/~ddehaven/8043340/v2/ We'll need a followup issue to clean up all the warnings that clang is now spitting out when building jdk... -DrD- > I think --with-sdk-name sounds good. Just make sure to document it very clearly to minimize confusion between --with-sysroot --with-devkit and --with-tools-path. We are gathering quite a few related options here. > > If this new option is used to set sysroot, then it should probably move closer to the sysroot setting, which is setup in BASIC_SETUP_DEVKIT. I realize you then need to find xcodebuild there already, using the TOOLCHAIN_PATH, but I think that's ok, since that tools is used specifically for finding a sysroot on mac. > > Overall, I like where this is going. > > /Erik > > On 2014-05-27 18:29, David DeHaven wrote: >> I tend to agree. How about --with-sdk-name=? SDKROOT implies a path, as would something like --with-sdk (and I could see that being confusing for someone building on Windows. >> >> I got successful builds on Friday. I'll make the above changes and post another iteration for review. >> >> -DrD- >> >>> It looks to me like that we can remove the option in jdk9 since it was deprecated in 8. It's a noop anyway though so shouldn't interfere with your work. >>> >>> I'm not sure if giving --with-sysroot an optional special format for macosx is the right way to go. It looks cleaner from one way, but also increases confusion I think. I prefer a special parameter, which helps setting sysroot as suggested. >>> >>> If you need a synonym for SYSROOT in macosx, that seems fine to me. >>> >>> /Erik >>> >>> On 2014-05-23 18:38, David DeHaven wrote: >>>> I'm combining this fix with another as it was starting to make my head split trying to keep the two separate, they're just too closely related. I'll start another review thread for the combined patches. >>>> >>>> -DrD- >>>> >>>>> Nobody should be using this any more, can I nuke it? >>>>> >>>>> BASIC_DEPRECATED_ARG_ENABLE(macosx-runtime-support, macosx_runtime_support) >>>>> >>>>> That hasn't done anything since JDK7, it was deprecated in 8 and shouldn't even be used in 8. >>>>> >>>>> -DrD- >>>>> >>>>>> Now that my mind is fresher and I've had my coffee... (and someones poked me in the ribs ;) >>>>>> >>>>>> MACOSX_SDK_PATH should be SDKROOT, which is what Apple uses when building via Xcode or xcodebuild, which would also promote that setting to the few remaining Xcode projects we have hanging around. We can use SYSROOT, but Apple's tools will just ignore it so I propose we add SDKROOT as a synonym for SYSROOT. Unfortunately the -F arguments still need to be absolute paths. >>>>>> >>>>>> We can eliminate the hard coded ApplicationServices paths by including ApplicationServices instead of it's sub-frameworks (and adjust the source accordingly), but we can't do that for JavaVM as we absolutely do NOT want to link against JavaVM, only JNF and JRS. >>>>>> >>>>>> >>>>>> We'll do something like: >>>>>> >>>>>> # assuming SYSROOT="$with_sysroot" already >>>>>> if test "x$OPENJDK_TARGET_OS" = xmacosx; then >>>>>> if test ! -d "$SYSROOT"; then >>>>>> # SYSROOT is not a directory, check if it's a symbolic name for an Xcode SDK >>>>>> SYSROOT=`$(XCODEBUILD) -sdk "$SYSROOT" -version | grep '^Path: ' | sed 's/Path: //'` >>>>>> if test ! -d "$SYSROOT"; then >>>>>> AC_MSG_ERROR([SYSROOT does not point to a valid path]) >>>>>> fi >>>>>> fi >>>>>> SDKROOT=$SYSROOT >>>>>> AC_SUBST(SDKROOT) >>>>>> fi >>>>>> >>>>>> This will eliminate any added configure arguments. >>>>>> >>>>>> (14 hours of build system hacking makes for a very muddled mind...) >>>>>> >>>>>> -DrD- >>>>>> >>>>>> >>>>>>> Hello David, >>>>>>> >>>>>>> I like that you incorporate the existing sysroot settings for this. I wonder though, what is the difference between --with-macosx-sdk-path and --with-sysroot? Do we really need two parameters for this? If it's actually a sysroot, couldn't we replace all uses of this variable with just SYSROOT and keep it more generic? >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> On 2014-05-23 08:16, David DeHaven wrote: >>>>>>>> Build systems take such a long time work on... >>>>>>>> >>>>>>>> I've changed the logic, I think for the better. I hijacked --with-sysroot, SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only change that's peppered throughout the forest is adding $(MACOSX_SDK_PATH) to the hard coded JavaVM.framework and ApplicationServices.framework paths, not to mention everything gets -isysroot/-iframework and not just the parts that needed JavaVM or ApplicationServices. The added SYSROOT logic is Mac specific so other platforms should be unaffected, JPRT should tell otherwise if not... >>>>>>>> >>>>>>>> I also added two configure args: >>>>>>>> --with-macosx-sdk name of Mac OS X SDK to build with, e.g., macosx10.7 >>>>>>>> [macosx] >>>>>>>> --with-macosx-sdk-path specify path of Mac OS X SDK to build with [probed] >>>>>>>> Please note that this version is against jdk9-dev with the following patches imported from other forests: >>>>>>>> hotspot: >>>>>>>> JDK-8043164 (jdk9/hs) >>>>>>>> >>>>>>>> jdk: >>>>>>>> JDK-8042440 (jdk9/client) >>>>>>>> JDK-8043646 (jdk9/client) >>>>>>>> JDK-8003900 (jdk9/client) >>>>>>>> >>>>>>>> >>>>>>>> Updated patches: >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/base >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/hotspot >>>>>>>> http://cr.openjdk.java.net/~ddehaven/8043340/v1/jdk >>>>>>>> >>>>>>>> -DrD- >>>>>>>> > From weijun.wang at oracle.com Fri May 30 01:04:53 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 30 May 2014 09:04:53 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: <53875715.6060307@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <81187D1C-26B0-40A3-A3F4-23BB24D99906@oracle.com> <53875715.6060307@oracle.com> Message-ID: <5387D935.5020603@oracle.com> On 5/29/2014 23:49, Henry Jen wrote: > > What I would like to confirm is after you install command line tools, is > there a xcodebuild somewhere? From your situation, I guess the answer is > NO. There is one inside /usr/bin, but I think it is the stub. Running it shows $ xcodebuild xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line instance. --Max > > Cheers, > Henry From kumar.x.srinivasan at oracle.com Fri May 30 01:05:00 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 29 May 2014 18:05:00 -0700 Subject: RFR(S): 8044363: Remove special build options for unpack200 executable In-Reply-To: <53879FCF.2050101@oracle.com> References: <538798AE.10807@oracle.com> <53879FCF.2050101@oracle.com> Message-ID: <5387D93C.4020506@oracle.com> > Looks good. The JBS bug needs noreg-build > > Thanks > Kumar > > > On 5/29/2014 1:29 PM, Mikael Vidstedt wrote: >> >> Please review the below fix which removes a couple of build options >> used when compiling/linking the unpack200 executable - specifically >> -xregs=no%appl and -xmemalign=4s. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8044363 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8044363/webrev.00/webrev/ >> >> Discussion: >> >> The -xregs=no%appl is supposed to be used when compiling system >> libraries [1], but unpack200 is an executable and so I missed making this comment in my earlier response. Sorry. For the record, the unpacker sources are also compiled as a library (libunpack.so), I have tested both the executable as well as the library version, and they seem to be working correctly. Kumar >> does not fall in that category. The -memalign=4s is supposed to help >> porting code [2] by having the compiler generate code which does not >> assume full natural data alignment, but the code in question is clean >> and does not require this option. >> >> Testing: >> >> Kumar graciously helped me test the change by manually >> packing/unpacking across different platforms. I'm taking suggestions >> on any further testing needed. >> >> Thanks, >> Mikael >> >> [1] http://docs.oracle.com/cd/E19205-01/819-5265/bjawv/index.html >> [2] http://docs.oracle.com/cd/E19205-01/819-5265/bjavc/index.html > From weijun.wang at oracle.com Fri May 30 01:28:03 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 30 May 2014 09:28:03 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> Message-ID: <5387DEA3.2030007@oracle.com> On 5/29/2014 23:56, David DeHaven 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? > > Apple installs stub binaries in /usr/bin, this exec's the real xcodebuild from the currently selected version of Xcode. If no copy of Xcode is installed it triggers the "You need to install Xcode" user experience. Apparently there's an option to only install the command line tools, I didn't know about that. It's the rightmost button in the dialog prompt. > > I'm curious if only installing the CL tools also installs at least one OS X SDK. If it doesn't then it's not terribly useful, except for maybe porting/building Unix command line tools. > Well, I guess it did. At least jdk9 builds successfully. My new Mavericks is installed on the 2nd disk of my Mac Mini. I guess it shouldn't see the old SDK on the 1st disk. Right? Where is the SDK located? /System/Library/Frameworks? They are quite some frameworks there. Thanks Max > -DrD- > From david.dehaven at oracle.com Fri May 30 02:59:06 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 29 May 2014 19:59:06 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <5387DEA3.2030007@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> Message-ID: <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> >> I'm curious if only installing the CL tools also installs at least one OS X SDK. If it doesn't then it's not terribly useful, except for maybe porting/building Unix command line tools. > > Well, I guess it did. At least jdk9 builds successfully. My new Mavericks is installed on the 2nd disk of my Mac Mini. I guess it shouldn't see the old SDK on the 1st disk. Right? > > Where is the SDK located? /System/Library/Frameworks? They are quite some frameworks there. No, the SDKs are in the app bundles. The frameworks in /System used to have headers installed with the developer tools, but Apple is moving away from that. The frameworks themselves are managed by the OS install/update. Maybe the command line tools still install headers there. run this: $ find /Library/Developer/CommandLineTools -name '*.sdk' I'm curious to see what's there... If the SDKs are there then we should be able to support building OpenJDK with just the command line tools installed. That won't be the case for closed source though, you still need the full Xcode app installed. -DrD- From weijun.wang at oracle.com Fri May 30 03:16:02 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 30 May 2014 11:16:02 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> Message-ID: <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> On May 30, 2014, at 10:59, David DeHaven wrote: > >>> I'm curious if only installing the CL tools also installs at least one OS X SDK. If it doesn't then it's not terribly useful, except for maybe porting/building Unix command line tools. >> >> Well, I guess it did. At least jdk9 builds successfully. My new Mavericks is installed on the 2nd disk of my Mac Mini. I guess it shouldn't see the old SDK on the 1st disk. Right? >> >> Where is the SDK located? /System/Library/Frameworks? They are quite some frameworks there. > > No, the SDKs are in the app bundles. The frameworks in /System used to have headers installed with the developer tools, but Apple is moving away from that. The frameworks themselves are managed by the OS install/update. Maybe the command line tools still install headers there. > > run this: > $ find /Library/Developer/CommandLineTools -name '*.sdk' Nothing. > > I'm curious to see what's there... If the SDKs are there then we should be able to support building OpenJDK with just the command line tools installed. > > That won't be the case for closed source though, you still need the full Xcode app installed. I only build jdk, haven't touched deploy etc. --Max > > -DrD- > From weijun.wang at oracle.com Fri May 30 07:59:59 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 30 May 2014 15:59:59 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> Message-ID: <53883A7F.1040006@oracle.com> On 5/30/2014 11:16, Wang Weijun wrote: >> run this: >> $ find /Library/Developer/CommandLineTools -name '*.sdk' > > Nothing. > I tried this again. The command line installation creates: 1. /Library/Developer/CommandLineTools 2. /usr/include 3. Many many /System/Library/Frameworks/.../Headers 4. Some examples and documentation --Max From Alan.Bateman at oracle.com Fri May 30 12:29:07 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 May 2014 13:29:07 +0100 Subject: 8043753: Drop javax.transaction from compact2 Message-ID: <53887993.5000502@oracle.com> This is a proposed change to the set of API packages in the compact2 and compact3 Profiles that we defined in Java SE 8 / JDK 8. The background to this is that compact2 includes the subset of the Java Transaction API (JTA) that Java SE defines. JTA isn't usually interesting for small devices but JDBC is and the JBDC API has API dependencies on a number of XA types defined in javax.transaction.xa. We've been looking at this again in the context of of moving to a truly modular JDK. For a modular JDK it would be highly desirable to have a JDBC module that has as few transitively dependencies as possible. The problem with a dependence on JTA is that the 3 exceptions in javax.transaction are RemoteException types and are only useful for RMI-IIOP. So we'd like to split these so that javax.transaction can live closer to CORBA and have javax.transaction.xa be closer to JDBC. In order to get there then compact2 (and thus compact3) will need to change. The compatibility impact of this is close is very low as it is highly unlikely that applications running on embedded systems would be making use of these 3 exceptions. The build changes are simple, it just changes PROFILE_2_RTJAR_INCLUDE_PACKAGES to include the xa package and then updates FULL_JRE_RTJAR_INCLUDE_TYPES to ensure that javax.transaction is included in the full JRE/JDK builds. Thanks, -Alan. diff --git a/make/profile-rtjar-includes.txt b/make/profile-rtjar-includes.txt --- a/make/profile-rtjar-includes.txt +++ b/make/profile-rtjar-includes.txt @@ -88,7 +88,7 @@ java/sql \ javax/rmi/ssl \ javax/sql \ - javax/transaction \ + javax/transaction/xa \ javax/xml \ org/w3c \ org/xml/sax \ @@ -223,7 +223,8 @@ javax/management/remote/rmi/_RMIConnection_Stub.class \ javax/management/remote/rmi/_RMIServerImpl_Tie.class \ javax/management/remote/rmi/_RMIServer_Stub.class \ - javax/rmi/*.class + javax/rmi/*.class \ + javax/transaction/*.class FULL_JRE_RTJAR_EXCLUDE_TYPES := From david.dehaven at oracle.com Fri May 30 14:49:00 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 30 May 2014 07:49:00 -0700 Subject: RFR: [9] 8043340 & 8043591: [macosx] Build system issues In-Reply-To: <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> References: <672CAA2A-F919-4F68-AF6A-E6AF5A062689@oracle.com> <406724F1-2C02-4846-A517-B7642BE405D3@oracle.com> <0251ED4C-4A42-435A-969F-091AA19F34AA@oracle.com> <537C5F0C.3090801@oracle.com> <537DBC0B.9040408@oracle.com> <0D9D2ED0-6488-4848-ABF5-ACA327B3378B@oracle.com> <0A28F875-7956-43C1-90D5-60FF1D8257D5@oracle.com> <537F0E74.7040709@oracle.com> <71C75CFA-5C04-4B0B-A70A-2F38D052017D@oracle.com> <0714A8B1-FC9F-462A-83D7-1261342A6878@oracle.com> <538307DB.7040702@oracle.com> <0E75CC6F-88A2-4CCE-A3F0-83EC1406E11B@oracle.com> <5385A123.3010303@oracle.com> <80992729-FFDE-4331-BEB0-BB4AEB69ABDD@oracle.com> Message-ID: <27EC7F2C-475B-45B4-8A29-D2EBA2E69B2E@oracle.com> > Here's the latest patch set: > http://cr.openjdk.java.net/~ddehaven/8043340/v2/ Just FYI, I ran a build only job on JPRT and it passed: Build Stats: 14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started -DrD- From david.dehaven at oracle.com Fri May 30 14:50:23 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 30 May 2014 07:50:23 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <53883A7F.1040006@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> <53883A7F.1040006@oracle.com> Message-ID: <8826B360-CB61-457E-88A1-4B9D847A9779@oracle.com> >>> run this: >>> $ find /Library/Developer/CommandLineTools -name '*.sdk' >> >> Nothing. >> > > I tried this again. The command line installation creates: > > 1. /Library/Developer/CommandLineTools > 2. /usr/include > 3. Many many /System/Library/Frameworks/.../Headers > 4. Some examples and documentation That's what I suspected. I'll have to rethink my patch for 8043340 a bit as I see no reason we can't support this for OpenJDK. -DrD- From david.dehaven at oracle.com Fri May 30 15:38:53 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 30 May 2014 08:38:53 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <8826B360-CB61-457E-88A1-4B9D847A9779@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> <53883A7F.1040006@oracle.com> <8826B360-CB61-457E-88A1-4B9D847A9779@oracle.com> Message-ID: >>>> run this: >>>> $ find /Library/Developer/CommandLineTools -name '*.sdk' >>> >>> Nothing. >>> >> >> I tried this again. The command line installation creates: >> >> 1. /Library/Developer/CommandLineTools >> 2. /usr/include >> 3. Many many /System/Library/Frameworks/.../Headers >> 4. Some examples and documentation > > That's what I suspected. I'll have to rethink my patch for 8043340 a bit as I see no reason we can't support this for OpenJDK. One more test for you: $ xcode-select --print-path Let me know what that reports (I suspect something like /Library/Developer/CommandLineTools/Developer). I'll have to change both places where we run xcodebuild to properly support this. -DrD- From mikael.vidstedt at oracle.com Fri May 30 16:29:05 2014 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 30 May 2014 09:29:05 -0700 Subject: RFR(S): 8044363: Remove special build options for unpack200 executable In-Reply-To: <5387D93C.4020506@oracle.com> References: <538798AE.10807@oracle.com> <53879FCF.2050101@oracle.com> <5387D93C.4020506@oracle.com> Message-ID: <5388B1D1.5030600@oracle.com> Kumar - Thanks for the review and the help testing this! Cheers, Mikael On 2014-05-29 18:05, Kumar Srinivasan wrote: > >> Looks good. The JBS bug needs noreg-build >> >> Thanks >> Kumar >> >> >> On 5/29/2014 1:29 PM, Mikael Vidstedt wrote: >>> >>> Please review the below fix which removes a couple of build options >>> used when compiling/linking the unpack200 executable - specifically >>> -xregs=no%appl and -xmemalign=4s. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044363 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8044363/webrev.00/webrev/ >>> >>> Discussion: >>> >>> The -xregs=no%appl is supposed to be used when compiling system >>> libraries [1], but unpack200 is an executable and so > > I missed making this comment in my earlier response. Sorry. > > For the record, the unpacker sources are also compiled as a library > (libunpack.so), I have > tested both the executable as well as the library version, and they > seem to be working > correctly. > > > Kumar > >>> does not fall in that category. The -memalign=4s is supposed to help >>> porting code [2] by having the compiler generate code which does not >>> assume full natural data alignment, but the code in question is >>> clean and does not require this option. >>> >>> Testing: >>> >>> Kumar graciously helped me test the change by manually >>> packing/unpacking across different platforms. I'm taking suggestions >>> on any further testing needed. >>> >>> Thanks, >>> Mikael >>> >>> [1] http://docs.oracle.com/cd/E19205-01/819-5265/bjawv/index.html >>> [2] http://docs.oracle.com/cd/E19205-01/819-5265/bjavc/index.html >> > From weijun.wang at oracle.com Sat May 31 01:11:35 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 31 May 2014 09:11:35 +0800 Subject: xcodebuild necessary on Mac? In-Reply-To: References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> <53883A7F.1040006@oracle.com> <8826B360-CB61-457E-88A1-4B9D847A9779@oracle.com> Message-ID: <13217B7B-EC82-4A41-A47D-1E2EBC8674A7@oracle.com> On May 30, 2014, at 23:38, David DeHaven wrote: >>>>> >>>>> run this: >>>>> $ find /Library/Developer/CommandLineTools -name '*.sdk' >>>> >>>> Nothing. >>>> >>> >>> I tried this again. The command line installation creates: >>> >>> 1. /Library/Developer/CommandLineTools >>> 2. /usr/include >>> 3. Many many /System/Library/Frameworks/.../Headers >>> 4. Some examples and documentation >> >> That's what I suspected. I'll have to rethink my patch for 8043340 a bit as I see no reason we can't support this for OpenJDK. > > One more test for you: > $ xcode-select --print-path /Library/Developer/CommandLineTools --Max > > Let me know what that reports (I suspect something like /Library/Developer/CommandLineTools/Developer). I'll have to change both places where we run xcodebuild to properly support this. > > -DrD- From david.dehaven at oracle.com Sat May 31 02:26:23 2014 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 30 May 2014 19:26:23 -0700 Subject: xcodebuild necessary on Mac? In-Reply-To: <13217B7B-EC82-4A41-A47D-1E2EBC8674A7@oracle.com> References: <30D5418B-96D9-448F-BBE0-366D200A87F5@oracle.com> <5386B552.7060605@oracle.com> <5387DEA3.2030007@oracle.com> <8349AE0E-4435-40DE-86FA-83CFD299253D@oracle.com> <4EB39E82-BE60-4A5D-8A13-95CDB438495E@oracle.com> <53883A7F.1040006@oracle.com> <8826B360-CB61-457E-88A1-4B9D847A9779@oracle.com> <13217B7B-EC82-4A41-A47D-1E2EBC8674A7@oracle.com> Message-ID: <13D05829-FEBD-412D-96A4-8DB57E6B309D@oracle.com> >>>>>> >>>>>> run this: >>>>>> $ find /Library/Developer/CommandLineTools -name '*.sdk' >>>>> >>>>> Nothing. >>>>> >>>> >>>> I tried this again. The command line installation creates: >>>> >>>> 1. /Library/Developer/CommandLineTools >>>> 2. /usr/include >>>> 3. Many many /System/Library/Frameworks/.../Headers >>>> 4. Some examples and documentation >>> >>> That's what I suspected. I'll have to rethink my patch for 8043340 a bit as I see no reason we can't support this for OpenJDK. >> >> One more test for you: >> $ xcode-select --print-path > > /Library/Developer/CommandLineTools Well at least xcode-select works... I think I just need to make space on my system for a 10.9 VM so I can play with this directly :/ -DrD- From ebourg at apache.org Sat May 31 13:35:15 2014 From: ebourg at apache.org (Emmanuel Bourg) Date: Sat, 31 May 2014 15:35:15 +0200 Subject: OpenJDK 8 compact profiles fail to build with make 4.0 Message-ID: <5389DA93.4080705@apache.org> Hi, I'd like to report an issue with the build for the OpenJDK 8 compact profiles. On Debian the build fails when PropertyChangeListener is removed from the pack200 classes: ## Starting profiles /usr/bin/find: `/home/ebourg/jdk8u-dev/build/images/lib': No such file or directory make[2]: *** No rule to make target '/home/ebourg/jdk8u-dev/build/images/beanless/java/util/jar/Pack200\$Packer.class', needed by '/home/ebourg/jdk8u-dev/build/images/libprofile_1/rt.jar'. Stop. make[2]: *** Waiting for unfinished jobs.... Removed method addPropertyChangeListener(java.beans.PropertyChangeListener) from java/util/logging/LogManager Removed method removePropertyChangeListener(java.beans.PropertyChangeListener) from java/util/logging/LogManager BuildJdk.gmk:113: recipe for target 'profile_1' failed make[1]: *** [profile_1] Error 2 /home/ebourg/jdk8u-dev//make/Main.gmk:147: recipe for target 'profiles-only' failed make: *** [profiles-only] Error 2 The same issue was reported last year on Arch Linux: http://mail.openjdk.java.net/pipermail/build-dev/2013-July/009557.html It looks like this error is caused by GNU Make 4.0 which is now the default in Debian. I was able to build the compact profiles after downgrading make to the version 3.81. OpenJDK 9 isn't affected by this issue because the add/removePropertyChangeListener() methods are already removed. Make 4.0 caused another regression (JDK-8028407) which has been fixed for OpenJDK 9. Could you also consider backporting it to OpenJDK 8 please? Thank you, Emmanuel Bourg From brian.burkhalter at oracle.com Tue May 6 19:02:51 2014 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 06 May 2014 19:02:51 -0000 Subject: OS X configure ignores --with-tools-dir Message-ID: <3AD40696-3F26-4D58-8C27-870798406DA9@oracle.com> Attempting to build JDK 8 on Mavericks I found the same problem: $ sh configure --with-debug-level=fastdebug --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin [?] checking for gcc... /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc configure: Resolving CC (as /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc) failed, using /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc directly. checking resolved symbolic links for CC... /Applications/Xcode4.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2 checking if CC is disguised ccache... no, keeping CC configure: Using i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build) C compiler version 2336.11.00) (located at /Applications/Xcode4.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2) checking whether the C compiler works... no configure: error: in `/Users/bpb/Work/CoreLibs/jdk/jdk8u-dev': configure: error: C compiler cannot create executables See `config.log' for more details configure exiting with result code 77 Thanks, Brina > On 04/30/2014 12:42 AM, Erik Joelsson wrote: > > > > On 2014-04-30 00:51, Dan Smith wrote: > >> Thanks Henry, that will force it to choose my referenced compiler. > >> > >> Still not clear whether this is intended behavior or not: is the > >> default toolchain-type (clang, apparently) supposed to trump an > >> explicit tools-dir? I.e., is this a bug, or just surprising but > >> intentional? > > I think this is intentional, but it could certainly still be discussed. > > I'm surprised clang is already picked as default however. Perhaps there > > is something else that's not working as intended causing this. > > We use 'xcodebuild -version' to determine xcode version, and choose > clang as default after 5.0. > > http://hg.openjdk.java.net/jdk9/jdk9/rev/77c150b417d8 > > --with-tools-dir specify where to find the toolchain, in this case, we > would hope it can correctly identify it's xcode 4, but it's not. > > Cheers, > Henry