[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