RFR: 8031668: (xxs) TOOLCHAIN_FIND_COMPILER unexpectedly resolves symbolic links

[Erik Joelsson]

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