If my memory serves me right, I believe we were uncertain if symlink
resolving was really the way to go and finally decided to do it because
a set configuration should not easily be changed without configure being
rerun.
Example: If a configuration finds compiler /path/to/A which is actually
a symlink to /path/to/B, then if that symlink is changed to point to
/path/to/C, perhaps by installing a new package on the system, then the
configuration should still be pointing to B until you rerun configure.
I agree that this usecase is hardly important when compared to the much
more common scenario that Mike encountered and so I would vote for
removing symlink resolving. I have encountered the same problem myself
but was able to resolve it by using command line flags which could
control the language used. I would rather avoid having to do that in the
future.
/Erik
On 2014-01-14 08:57, Magnus Ihse Bursie wrote:
On 2014-01-14 02:46, Mike Duigou wrote:
Hello all;
This is a very small change. Currently when TOOLCHAIN_FIND_COMPILER
evaluates a compiler it resolves any symbolic links. This behaviour
thwarts compiler setups that use a single executable and multiple
symbolic links that "curry" configuration information into the link
name.
http://cr.openjdk.java.net/~mduigou/JDK-8031668/0/webrev/
I wrote this in the bug but it's probably better to have a discussion
here, so I'll repeat it:
Unfortunately, it's not just so simple that we can remove the symbolik
link resolution. :-(
There's quite a dance going on in TOOLCHAIN_FIND_COMPILER, trying to
locate a proper compiler in a way that works robust on all systems
(that we have encountered so far, at least).
That being said, we've also run into the problem you describe before,
in the AIX port, where the same compiler is either C or C++ depending
on it's name.
So we have two conflicting goals (resolve and do not resolve) here. :(
I'm not quite sure of the best way forward here.
/Magnus
