Missing lib on linking libc WITH_LIBCPLUSPLUS

Volodymyr Kostyrko c.kworr at gmail.com
Tue Oct 2 21:57:30 UTC 2012


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.


More information about the freebsd-stable mailing list