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.
/Magnus
Thanx!
J
