03.10.2012 00:48, Dimitry Andric wrote:
Bingo. Yes, disabling ccache makes everything work.
please ping the ccache folk about this. It *shouldn't* matter. :)
In this case, ccache apparently does not realize that the world stage is
using the toolchain built during the cross-tools stage, which usually is
in /usr/obj/usr/src/tmp/usr/bin.
This toolchain uses another include and lib path, e.g. it only refers to
headers and libraries under /usr/obj, specifically *not* those in the
base system.
In Volodymyr's original log, you can see /usr/bin/ld being invoked by
the compiler driver, not /usr/obj/usr/src/tmp/usr/bin/ld. I think
ccache invokes /usr/bin/cc, instead of /usr/obj/usr/src/tmp/usr/bin/cc.
Normally ccache searches the PATH to find the 'real' cc executable, but
I am not sure why this goes wrong during the world stage. It would be
interesting to see some verbose logging from ccache, to see how it finds
the cc executable here.
That's also a good catch. My system is configured according to
/usr/ports/devel/ccache/files/ccache-howto-freebsd.txt.in and
CCACHE_PATH is set to /usr/bin:/usr/local/bin. Can I ask you what is a
preferrred way of dealing with the PATH in the buildworld?
1. Rely on what environment contains.
2. Hardcode some sane default for ccache.
--
Sphinx of black quartz judge my vow.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
