[rfc] Avoid failure when compiler is wrapped.

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Wed Jan 27 20:04:44 UTC 2016

On 2016-01-27 17:54, Jiri Vanek wrote:
> On 01/27/2016 11:09 AM, Magnus Ihse Bursie wrote:
>> On 2016-01-25 21:38, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> Hello!
>>>> When compiler is wrapped, the configure phase of build fails:
>>>> [...]
>>>> checking for gcc... /usr/lib64/cscppc/gcc
>>>> configure: Resolving CC (as /usr/lib64/cscppc/gcc) failed, using
>>>> /usr/lib64/cscppc/gcc directly.
>>>> 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: "Usage:"
>>>> configure: error: GCC compiler is required. Try setting 
>>>> --with-tools-dir.
>>>> configure exiting with result code 1
>>>>   From time to time I'm building RPMS for fedora  with wrapped 
>>>> compiler to be
>>>>   able to investigate C
>>>> code changes. Added is patch, which is allowing to walk around the 
>>>> issue.
>>>> I'm wondering if this is still desired behaviour. or if it can be 
>>>> better
>>>> iff-ed out to be by default
>>>> on, but eg only disablef on AIX.
>>>> CCed is Andrew, who is facing similar issue on Gentoo.
>>>>     Thanx!
>>>>     J.
>>> The Gentoo issue was different; it's related to distcc failing the 
>>> version
>>> test, rather than symlink issues.
>>> I think this block should be removed, not just comment out, if not 
>>> needed.
>>> But first, I think we need to know why the dereferencing is there.
>>> Can someone at Oracle shed some light on this?
>> Maybe a glow of twilight. :) This check was added quite early in the 
>> new build system and was
>> included in the original integration of the new build system into 
>> mainline. I remember vaguely that
>> we had issues with some machines with strange setups which turned out 
>> to have unexpected symlinks.
>> So we thought it was better to clearly show in the configure log 
>> which compiler *really* was used.
>>  From the hg history, I also see that about a year ago, I added this 
>> comment in JDK-8034788:
>>   # FIXME: This test should not be needed anymore; we don't do that 
>> for any platform.
>> So maybe we should live up to that fixme, and remove the check. :-)
>> I just realized that we can still keep ability to debug broken 
>> systems by resolving the symlink, but
>> just printing the result and not modifying the path to the CC we will 
>> use. I opened
>> https://bugs.openjdk.java.net/browse/JDK-8148351 for this.
> Thank you for this Magnus.  I will try to prepare regualr webrev based 
> on your suggestion. If you fix it in meantime, just let us know :)

I posted "RFR: JDK-8148351 Only display resolved symlink for compiler, 
do not change path" to this list shortly after my previous comment to you.


> Thanx!
>   J

More information about the build-dev mailing list