On Jan 14 2014, at 01:34 , Erik Joelsson <erik.joels...@oracle.com> wrote:
> 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 would expect that this situation would be fairly uncommon. It would be nice to be able to detect it and require configure rerun but that doesn't seem practical. We could track the resolved location of the compiler and complain if it changes but that seems like too much additional effort. > 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 >
