This has bitten me before and for the same reason. I'm not sure why we
opted to do it this way, but it was probably due to wanting to control
ccache ourselves. I think it's probably not really required to resolve
the symlinks. I would like to get Magnus input on this too. (which will
have to wait until Jan 7.)
/Erik
On 2013-12-19 06:37, Mike Duigou wrote:
I am working with a compiler toolchain that packages it's C and C++ compilers
in a single executable and then uses symbolic links to disambiguate which
function is being requested. Want C? Invoke a symbolic link. Want C++? Invoke a
different symbolic link. Same story with it's linkers.
Anyway, this setup runs into problems with the current toolchain.m4 function
TOOLCHAIN_FIND_COMPILER which includes
TEST_COMPILER="[$]$1"
BASIC_REMOVE_SYMBOLIC_LINKS(TEST_COMPILER)
...
$1="$TEST_COMPILER"
This results in the stripping of the identifying symbolic links away and
leaving the compiler path as only the raw executable (which happens to default
to being a C compiler).
Is removing the symbolic links actually necessary or required? For my purposes commenting
out the final statement, $1="$TEST_COMPILER", results in the right executable
name (one of the symbolic links) being written to the spec.gmk
I was also surprised that removing of symbolic links from disguised ccache
doesn't consider the --disable-ccache option. In this case it should probably
just ignore any user trickery and attempt to proceed naively with compiler it's
been given.
Mike
