RFA: 8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links AND 8148351: Only display resolved symlink for compiler, do not change path

[Rob McKenna]

Yep - approved. Thanks for addressing the problem.

    -Rob

On 20/06/18 11:48, Severin Gehwolf wrote:
> Hi Rob,
> 
> Due to this conflict we've decided to change the JDK 8 patch for
> 8148351. It's been reviewed by Erik Joelsson from the build group and
> it does not seem to have the conflict the original patch had. Is it
> still OK to push it?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8148351
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.02/
> Review of the above:
> http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022447.html
> hg-export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch
> 
> Thanks,
> Severin
> 
> 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
> > 
> > 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.
> > 
> > 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
> > 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-8031
> > > > > > 668/webrev.01/
> > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8
> > > > > > 031668/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-8148
> > > > > > 351/webrev.01/
> > > > > > hg export: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8
> > > > > > 148351/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
> > 
> >