Hello,
On 2018-06-19 06:30, Severin Gehwolf wrote:
Hi Kevin,
Thanks for your help! Adding in build-dev for additional input.
On Tue, 2018-06-19 at 13:51 +0100, Kevin Walls wrote:
Hi Severin -
Ah, actually there's a conflict with the way we build, where we use
ccache in the path, and it no longer likes it with this change:
Our build system jprt fails, with the configure output:
...
checking flags for boot jdk java command for small workloads...
-XX:+UseSerialGC -Xms32M -Xmx512M
configure: Using default toolchain gcc (GNU Compiler Collection)
checking for gcc... /opt/jprt/products/P1/ccache2.4/bin/gcc
checking resolved symbolic links for CC...
/opt/jprt/products/P1/ccache2.4/bin/ccache
configure: error: /opt/jprt/products/P1/ccache2.4/bin/gcc is a symbolic
link to ccache. This is not supported.
configure: Please use --enable-ccache instead of providing a wrapped
compiler.
configure exiting with result code 1
Erik, Magnus, how do you do this for your JDK 9+ builds? Is there a way
to use "--enable-ccache" for JDK 8 builds?
We don't. The problem here is that the build machines we have for 8 have
ccache installed as a gcc wrapper. This was done back in 7 with the
intention of transparently improving build performance (but in reality
it didn't). Because of this situation, we implemented a workaround for 8
where we explicitly don't accept ccache as gcc wrapper and look for gcc
elsewhere instead. Our build machines for 9 do not have cache installed
at all (it's still in the devkit, but not as a wrapper, and since we saw
no benefit for our use case we don't use ccache anyway).
The change being backported here removes the workaround that allows the
build to function with the ccache wrapper on the system. I don't think
that's a good idea for 8. We need to retain that workaround so the patch
needs to be modified before going into 8u.
Reproducing this issue locally should be pretty simple. Create a dummy
script named ccache somewhere. Put a symlink named gcc, pointing to that
ccache script first in your path. Then run configure.
/Erik
It's the second change, 8148351, which triggers this failure, as it
removes lines at 549 onwards which previously tried to handle the ccache
in the path case.
Right. It's 8148351 which we'd be interested in.
Yes, in 9 onward we abort the build if ccache is found at the end of a
link, we haven't done that in jdk 8 before... Would retaining the ccache
handling code in toolchain.m4 still give you the behaviour you want from
doing the backport?
Thanks,
Severin
Thanks
Kevin
On 19/06/2018 07:23, Severin Gehwolf wrote:
Hi Kevin,
On Mon, 2018-06-18 at 21:11 +0100, Kevin Walls wrote:
Hi -- I've been doing various 8u build changes recently -- would you
like me to push this, with the regenerated autogen-generated file?
It would be very much appreciated!
Thanks,
Severin
On 18/06/2018 17:45, Rob McKenna wrote:
Approved. Please work with the appropriate team to find a sponsor.
-Rob
On 18/06/18 16:36, Severin Gehwolf wrote:
Hi,
Please approve these two backports to JDK 8u-dev which are already in
JDK 9 and better.
8031668: TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/webrev.01/
hg export:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8031668/JDK-8031668.jdk8.export.patch
8148351: Only display resolved symlink for compiler, do not change path
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/webrev.01/
hg export:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8148351/JDK-8148351.jdk8.export.patch
Bug 8031668 is a dependency for 8148351 which actually fixes the
wrapped compiler issue on the JDK 8 tree. The JDK 8 patch of 8031668 is
the same as for JDK 9, modulo some context changes. After the JDK 8
patch of 8031668, the JDK 9 patch of 8148351 imports as is.
The issue at hand is that one cannot build the JDK 8 tree with certain
compiler wrappers such as cscppc. It currently fails with:
configure: Using default toolchain gcc (GNU Compiler Collection)
checking for gcc... /usr/lib64/cscppc/gcc
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: ""
configure: error: A gcc compiler is required. Try setting --with-tools-dir.
configure exiting with result code 1
After both backports configure with a wrapped GCC succeeds.
Please note that I'd need an Oracle sponsor for getting this pushed to
jdk8u-dev since both changes require re-generation of generated-
configure.sh
Thanks,
Severin
