OS X configure ignores --with-tools-dir

[Brian Burkhalter]

Attempting to build JDK 8 on Mavericks I found the same problem:

$ sh configure --with-debug-level=fastdebug --with-tools-dir=/Applications/Xcode4.app/Contents/Developer/usr/bin
[…]
checking for gcc... /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc
configure: Resolving CC (as /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc) failed, using /Applications/Xcode4.app/Contents/Developer/usr/bin/gcc directly.
checking resolved symbolic links for CC... /Applications/Xcode4.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
checking if CC is disguised ccache... no, keeping CC
configure: Using i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build) C compiler version 2336.11.00) (located at /Applications/Xcode4.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2)
checking whether the C compiler works... no
configure: error: in `/Users/bpb/Work/CoreLibs/jdk/jdk8u-dev':
configure: error: C compiler cannot create executables
See `config.log' for more details
configure exiting with result code 77

Thanks,

Brina
> On 04/30/2014 12:42 AM, Erik Joelsson wrote:
> >
> > On 2014-04-30 00:51, Dan Smith wrote:
> >> Thanks Henry, that will force it to choose my referenced compiler.
> >>
> >> Still not clear whether this is intended behavior or not: is the
> >> default toolchain-type (clang, apparently) supposed to trump an
> >> explicit tools-dir?  I.e., is this a bug, or just surprising but
> >> intentional?
> > I think this is intentional, but it could certainly still be discussed.
> > I'm surprised clang is already picked as default however. Perhaps there
> > is something else that's not working as intended causing this.
> 
> We use 'xcodebuild -version' to determine xcode version, and choose 
> clang as default after 5.0.
> 
> http://hg.openjdk.java.net/jdk9/jdk9/rev/77c150b417d8
> 
> --with-tools-dir specify where to find the toolchain, in this case, we 
> would hope it can correctly identify it's xcode 4, but it's not.
> 
> Cheers,
> Henry