Why does xcode 4.3.2 hang when archiving?

Question

When I attempt to archive a build, xcode hangs with the colorful spinny wheel of death. It used to work fine, but I can no longer browse the archive anymore unless I delete

Answer 1

Quick Solution: execute the following: xcode-select -switch /Applications/Xcode.app/Contents/Developer/

How I came to the solution:

Turned on opendirectoryd debug logging: "odutil set log debug"

Searched around inside the /var/logs/opendirectoryd.log files.

I kept seeing this block of logs spammed over and over again:

---

2012-04-12 11:29:28.420 CDT - 31053.1185984, Module: SystemCache - Signaling semaphores for more work

2012-04-12 11:29:28.420 CDT - 31053.1185984, Module: SystemCache - Finalizing response object 0x7fae5b21acb0, request is complete

2012-04-12 11:29:28.420 CDT - 31053 - Client: 'xcodebuild', exited with 0 session(s), 0 node(s) and 0 active request(s)

2012-04-12 11:29:28.421 CDT - Trigger - new node trigger watching for 'opendirectoryd:nodes;(register|unregister);.*'

2012-04-12 11:29:28.421 CDT - semaphore_wait will wait - maximum number of membership calls are already in flight

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Client: xcodebuild, UID: 501, EUID: 501, GID: 20, EGID: 20

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Adding to global request list - new count 1

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - mbr_identifier_to_uuid request, UID: 501

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - semaphore_wait will wait - max_active_work

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - semaphore_wait will wait - workq

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Submitting to pipeline

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - executing request pipeline

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Cache hit - dev14 (0x59574CC0)

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Submitting to response pipeline

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - executing response pipeline - 0x10ba2f670

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - mbr_identifier_to_uuid completed, delivered 1 result

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Removing from global request list

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Signaling semaphores for more work

2012-04-12 11:29:28.421 CDT - 31053.1185985, Module: SystemCache - Finalizing response object 0x10ba2f670, request is complete

2012-04-12 11:29:28.421 CDT - 31053 - Client: 'xcodebuild', exited with 0 session(s), 0 node(s) and 0 active request(s)

2012-04-12 11:29:28.422 CDT - Trigger - new node trigger watching for 'opendirectoryd:nodes;(register|unregister);.*'

2012-04-12 11:29:28.422 CDT - semaphore_wait will wait - maximum number of membership calls are already in flight

2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - Client: xcodebuild, UID: 501, EUID: 501, GID: 20, EGID: 20

2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - Adding to global request list - new count 1

2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - mbr_identifier_to_uuid request, UID: 501

2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - semaphore_wait will wait - max_active_work

2012-04-12 11:29:28.422 CDT - 31053.1185986, Module: SystemCache - semaphore_wait will wait - workq

I searched for one of these strings in google and came up with the following solution hidden away on apple's developer forum:

"It seems that the old xcodebuild command was left lying around by the new Xcode installer. After executing 'xcode-select -switch /Applications/Xcode.app/Contents/Developer/' and a 'make clean' the project built perfectly."

Indeed, it works now. Must have been some weird symbolic link that wasn't correct. Lots of other people seem to have issues with opendirectoryd and a broken sym link causing a large CPU spike.