TOOLCHAIN_FIND_COMPILER removing symlinks? (original) (raw)

Erik Joelsson 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.)

/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 TOOLCHAINFINDCOMPILER which includes TESTCOMPILER="[$]$1" BASICREMOVESYMBOLICLINKS(TESTCOMPILER) ... $1="$TESTCOMPILER" 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="1="1="TESTCOMPILER", 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

More information about the build-dev mailing list