Hi Erik, On Tue, 2018-06-19 at 07:06 -0700, Erik Joelsson wrote: > Hello, > > On 2018-06-19 06:30, Severin Gehwolf wrote: > > Hi Kevin, > > > > Thanks for your help! Adding in build-dev for additional input. > > > > On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote: > > > Hi Severin - > > > > > > Ah, actually there's a conflict with the way we build, where we use > > > ccache in the path, and it no longer likes it with this change: > > > > > > Our build system jprt fails, with the configure output: > > > ... > > > checking flags for boot jdk java command for small workloads... > > > -XX:+UseSerialGC -Xms32M -Xmx512M > > > configure: Using default toolchain gcc (GNU Compiler Collection) > > > checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc > > > checking resolved symbolic links for CC... > > > /opt/jprt/products/P1/ccache2.4/bin/ccache > > > configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic > > > link to ccache. This is not supported. > > > configure: Please use --enable-ccache instead of providing a wrapped > > > compiler. > > > configure exiting with result code 1 > > > > Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way > > to use "--enable-ccache" for JDK 8 builds? > > We don't. The problem here is that the build machines we have for 8 have > ccache installed as a gcc wrapper. This was done back in 7 with the > intention of transparently improving build performance (but in reality > it didn't). Because of this situation, we implemented a workaround for 8 > where we explicitly don't accept ccache as gcc wrapper and look for gcc > elsewhere instead. Our build machines for 9 do not have cache installed > at all (it's still in the devkit, but not as a wrapper, and since we saw > no benefit for our use case we don't use ccache anyway). > > The change being backported here removes the workaround that allows the > build to function with the ccache wrapper on the system. I don't think > that's a good idea for 8. We need to retain that workaround so the patch > needs to be modified before going into 8u.
Sigh. Back to the drawing board ;-) > Reproducing this issue locally should be pretty simple. Create a dummy > script named ccache somewhere. Put a symlink named gcc, pointing to that > ccache script first in your path. Then run configure. Thanks, yes. I've got that reproduced. Cheers, Severin > /Erik > > > It's the second change, 8148351, which triggers this failure, as it > > > removes lines at 549 onwards which previously tried to handle the ccache > > > in the path case. > > > > Right. It's 8148351 which we'd be interested in. > > > > > Yes, in 9 onward we abort the build if ccache is found at the end of a > > > link, we haven't done that in jdk 8 before... Would retaining the ccache > > > handling code in toolchain.m4 still give you the behaviour you want from > > > doing the backport? > > > > Thanks, > > Severin > > > > > Thanks > > > Kevin > > > > > > > > > > > > > > > > > > On 19/06/2018 07:23, Severin Gehwolf wrote: > > > > Hi Kevin, > > > > > > > > On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote: > > > > > Hi -- I've been doing various 8u build changes recently -- would you > > > > > like me to push this, with the regenerated autogen-generated file? > > > > > > > > It would be very much appreciated! > > > > > > > > Thanks, > > > > Severin > > > > > > > > > On 18/06/2018 17:45, Rob McKenna wrote: > > > > > > Approved. Please work with the appropriate team to find a sponsor. > > > > > > > > > > > > -Rob > > > > > > > > > > > > On 18/06/18 16:36, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Please approve these two backports to JDK 8u-dev which are > > > > > > > already in > > > > > > > JDK 9 and better. > > > > > > > > > > > > > > 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic > > > > > > > links > > > > > > > webrev: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/ > > > > > > > hg export: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch > > > > > > > > > > > > > > 8148351: Only display resolved symlink for compiler, do not > > > > > > > change path > > > > > > > webrev: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/ > > > > > > > hg export: > > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch > > > > > > > > > > > > > > Bug 8031668 is a dependency for 8148351 which actually fixes the > > > > > > > wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of > > > > > > > 8031668 is > > > > > > > the same as for JDK 9, modulo some context changes. After the JDK > > > > > > > 8 > > > > > > > patch of 8031668, the JDK 9 patch of 8148351 imports as is. > > > > > > > > > > > > > > The issue at hand is that one cannot build the JDK 8 tree with > > > > > > > certain > > > > > > > compiler wrappers such as cscppc. It currently fails with: > > > > > > > > > > > > > > configure: Using default toolchain gcc (GNU Compiler Collection) > > > > > > > checking for gcc... /usr/lib64/cscppc/gcc > > > > > > > checking resolved symbolic links for CC... /usr/bin/cscppc > > > > > > > checking if CC is disguised ccache... no, keeping CC > > > > > > > configure: The C compiler (located as /usr/bin/cscppc) does not > > > > > > > seem to be the required gcc compiler. > > > > > > > configure: The result from running with --version was: "" > > > > > > > configure: error: A gcc compiler is required. Try setting > > > > > > > --with-tools-dir. > > > > > > > configure exiting with result code 1 > > > > > > > > > > > > > > After both backports configure with a wrapped GCC succeeds. > > > > > > > > > > > > > > Please note that I'd need an Oracle sponsor for getting this > > > > > > > pushed to > > > > > > > jdk8u-dev since both changes require re-generation of generated- > > > > > > > configure.sh > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > >
