----- Original Message ----- > 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.
Thanks for the feedback. I can understand why it was added. Simple verbosity at appropriate points can help debug a lot of these configuration issues. Should I go ahead and create a patch for this or are you already working on it? An AC_MSG_NOTICE or AC_MSG_WARNING seems sufficient to help debug broken systems. > > /Magnus > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
