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

[Erik Joelsson]

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.

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.

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