TOOLCHAIN_FIND_COMPILER removing symlinks?
erik.joelsson at oracle.com
Thu Dec 19 09:36:13 UTC 2013
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.)
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
> 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.
More information about the build-dev