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

[Kevin Walls]

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