OS X: ./configure fails with latest Command Line Tools installed (instead of Xcode)

[evocateur]

I was able to compile 0.8.1 successfully, but now I can't even get through ./configure.

[~/src/scratch/node-v0.8.2]$ gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
[~/src/scratch/node-v0.8.2]$ ./configure --prefix=$HOME/src/scratch --without-npm
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [],
                       'libraries': []},
  'variables': { 'host_arch': 'x64',
                 'node_install_npm': 'false',
                 'node_install_waf': 'true',
                 'node_no_strict_aliasing': 0,
                 'node_prefix': '/Users/daniel/src/scratch',
                 'node_shared_openssl': 'false',
                 'node_shared_v8': 'false',
                 'node_shared_zlib': 'false',
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_openssl': 'true',
                 'target_arch': 'x64',
                 'v8_no_strict_aliasing': 0,
                 'v8_use_snapshot': 'true'}}
creating  ./config.gypi
creating  ./config.mk
xcode-select: Error: No Xcode is selected. Use xcode-select -switch /Applications/Xcode.app to select /Applications/Xcode.app, or see the xcode-select manpage (man xcode-select) for further information.

Traceback (most recent call last):
  File "tools/gyp_node", line 58, in <module>
    run_gyp(gyp_args)
  File "tools/gyp_node", line 18, in run_gyp
    rc = gyp.main(args)
  File "./tools/gyp/pylib/gyp/__init__.py", line 480, in main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "./tools/gyp/pylib/gyp/generator/make.py", line 2082, in GenerateOutput
    part_of_all=qualified_target in needed_targets)
  File "./tools/gyp/pylib/gyp/generator/make.py", line 764, in Write
    self.Pchify))
  File "./tools/gyp/pylib/gyp/generator/make.py", line 1137, in WriteSources
    cflags = self.xcode_settings.GetCflags(configname)
  File "./tools/gyp/pylib/gyp/xcode_emulation.py", line 259, in GetCflags
    sdk_root = self._SdkPath()
  File "./tools/gyp/pylib/gyp/xcode_emulation.py", line 248, in _SdkPath
    return os.path.join(self._GetSdkBaseDir(), '%s.sdk' % sdk_root)
  File "./tools/gyp/pylib/gyp/xcode_emulation.py", line 234, in _GetSdkBaseDir
    raise Exception('Error %d running xcode-select' % job.returncode)
Exception: Error 1 running xcode-select

I'm using the Command Line Tools for Xcode - June 2012 package available at https://developer.apple.com/downloads/

I installed the latest Xcode (4.3.3) on another machine that was previously using the CLT, and it does compile there. Perhaps this is a gyp issue?

[TooTallNate]

Well it looks like xcode-select is invoked by gyp, and something isn't configured properly on your machine for it to output the correct values. You should try doing what it's recommending:

xcode-select: Error: No Xcode is selected. Use xcode-select -switch /Applications/Xcode.app to select /Applications/Xcode.app, or see the xcode-select manpage (man xcode-select) for further information.

That is:

$ xcode-select -switch /Applications/Xcode.app

[evocateur]

Except, with the Command Line Tools installed, I don't have /Applications/Xcode.app

This worked fine on 0.8.1 with only the Command Line Tools installed. Why does gyp insist on having full-blown Xcode now?

[TooTallNate]

Hhmm, could have something to do with the latest gyp upgrade. @bnoordhuis Any ideas?

[TooTallNate]

@evocateur If the command line tools package installs its files into /Developer, then try running:

$ sudo xcode-select -switch /Developer

[evocateur]

Since Xcode 4.3, /Developer no longer exists.

The Command Line Tools package basically extracts the headers and other utilities directly into their standard locations. xcodebuild and xcode-select are directly installed to /usr/bin/, all the dylibs are under /usr/lib/ and such.

[TooTallNate]

Well perhaps just sudo xcode-select -switch / then...

[evocateur]

According to Homebrew/legacy-homebrew#10245 , this causes issues with homebrew (which has it's own issues with CLT, per Homebrew/legacy-homebrew#10510).

At this point, I'll just sacrifice the disk space and stop whining. You might want to put some sort of note in the wiki or something about requiring full Xcode, though.

Thanks for the attentive response, @TooTallNate

[ghost]

Just ran into this as well (compiling directly from source, only Xcode Command Line Tools installed). sudo xcode-select -switch / worked like a charm. Thanks!

[Sharpie]

This should probably be re-opened and dealt with. Using xcode-select to set the root path to / works---but then the version of xcodebuild that ships with the Command Line Tools will hang in an infinite loop instead of erroring out gracefully. Users who only install the command line tools should probably leave the XCode path unset since they don't actually have XCode.app.

[bnoordhuis]

It's not for us to fix, it's a gyp bug (if it is a bug).

[Sharpie]

It's not for us to fix, it's a gyp bug (if it is a bug).

Fair enough. Since the build stopped working in 0.8.2, which version of GYP was used in 0.8.1 and which version was shipped in 0.8.2? I didn't see anything related to GYP versions in the ChangeLog.

[bnoordhuis]

Since the build stopped working in 0.8.2, which version of GYP was used in 0.8.1 and which version was shipped in 0.8.2?

r1214 with one out-of-tree patch that fixed a 'argument list too long' error (since fixed upstream). 0.8.2 ships with r1426. r1237 (bnoordhuis/gyp@3019d85) is the revision that started using xcode-select.

[Sharpie]

Awesome. Thanks for the info.

[Sharpie]

Also, I would classify this as a bug since Node will build fine under the CLT even if xcode-select is pointed at a totally bogus path:

mkdir -p $HOME/p0rn
sudo xcode-select -switch $HOME/p0rn

[bnoordhuis]

Does this patch help?

diff --git a/tools/gyp_node b/tools/gyp_node
index 5c4882f..02a8c2d 100755
--- a/tools/gyp_node
+++ b/tools/gyp_node
@@ -45,6 +45,8 @@ if __name__ == '__main__':

   # There's a bug with windows which doesn't allow this feature.
   if sys.platform != 'win32':
+    # Force Makefile output. See #3681.
+    args.extend(['-f', 'make'])

     # Tell gyp to write the Makefiles into output_dir
     args.extend(['--generator-output', output_dir])

[Sharpie]

Unfortunately, that patch didn't help.

According to the previously posted traceback, the root of the problem is in the _GetSdkBaseDir function in tools/gyp/pylib/gyp/xcode_emulation. Specifically, the code does not make any allowance for a non-zero exit condition from xcode-select---which is precisely what happens if someone has a clean install of OS X 10.7+ and just installs the Command Line Tools.

The ultimate issue is that the Command Line Tools don't include multiple SDKs so the whole operation of figuring out what the SDK root is should be skipped if XCode.app is not installed. But, this work probably needs to be punted upstream to GYP.

[TooTallNate]

@Sharpie Nice detective work. This is definitely a gyp bug, and it sounds like you're on the right track to writing a patch to fix it. Has anyone created an upstream issue to the gyp issue tracker yet?

[Sharpie]

it sounds like you're on the right track to writing a patch to fix it. Has anyone created an upstream issue to the gyp issue tracker yet?

I'm slowly working my way towards getting an issue open but I'm not a heavy Node user so I really don't have a dog in the fight to motivate me other than being tired of resolving the same issue over and over on the Homebrew tracker. If someone who knows GYP well gets around to writing a patch before I muster the spare time to do so, here is the code we use to detect XCode.app in Homebrew.

Basically, we flag a full XCode installation as being present if:

• /Developer/Applications/XCode.app exists or /Applications/XCode.app exists.
• mdfind kMDItemCFBundleIdentifier==<id> returns a valid path where <id> is either com.apple.Xcode or com.apple.dt.Xcode.

[Sharpie]

Allright, logged on the gyp tracker as issue 292.

[ryu1kn]

I was trying to install nodejs using nvm and got the same errors listed at the top of this thread. I could install node by changing the access rights for /usr/share/xcode-select. If it could be of any help to others here's what i did...

After I did sudo xcode-select -switch /Application/Xcode.app, I got slightly different messages:

...
                 'v8_no_strict_aliasing': 1,
                 'v8_use_snapshot': 'true'}}
creating  ./config.gypi
creating  ./config.mk
xcode-select: Error: Incorrect permissions for data file at '/usr/share/xcode-select/xcode_dir_link'. Run xcode-select -switch <xcode_folder_path> to reset the path to the Xcode folder.

Traceback (most recent call last):
  File "tools/gyp_node", line 58, in <module>
    run_gyp(gyp_args)
...

I checked out the permission for xcode-select and found out that no one except root can access to the dir. So I did chmod a+rx xcode-select After that installation went perfectly fine.

os x 10.8.1, xcode 4.4.1, CLT installed

[springmeyer]

Also just hit this with node v0.10.16 when setting up a new machine. It looks like the gyp issue has been fixed upstream: http://code.google.com/p/gyp/issues/detail?id=292#makechanges.

Does this mean that the blocker is now node or node-gyp pulling in a new gyp version?

[springmeyer]

Realizing now that the patch I found above has not actually been accepted yet and even so upgrading the gyp version to trunk breaks node-gyp since the gyp is now bash (and node-gyp must execute as python).

After trying sudo xcode-select -switch only to hit the hang when running node-gyp in xcrun as mentioned above, I was able to restore my default settings for xcode-select by doing rm /usr/share/xcode-select/*.

For the benefit of others like me that might be stuck tethering (and therefore with no ability to download xcode to work around this) I was able to get node-gyp working like:

# find your node-gyp directory
cd ~/.nvm/v0.10.16/lib/node_modules/npm/node_modules/node-gyp/gyp/
# download the proposed patch for http://code.google.com/p/gyp/issues/detail?id=292#makechanges
curl -o issue_292.diff https://codereview.chromium.org/download/issue14887003_1_2.diff
patch pylib/gyp/xcode_emulation.py issue_292.diff
``

[springmeyer]

fix finally landed in gyp master https://code.google.com/p/gyp/source/detail?r=1819 thanks to the work of @mistydemeo

[indutny]

See #6730