[rfc] Avoid failure when compiler is wrapped.

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Wed Jan 27 10:09:21 UTC 2016


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.

/Magnus



More information about the build-dev mailing list