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

[Severin Gehwolf]

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
> 
>