Apple Intelligence is now available on iPhone, iPad, and Mac!

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Command Line Tools installs the latest version of clang (and others) in /Library/Developer/CommandLineTools/... but not in /usr/bin/

I've upgraded Xcode to the latest 5.1 Installed Command Line Tools via xcode-select --install Homebrew tells me "A newer Command Line Tools release is available"

brew --config:

Xcode: 5.1 CLT: 5.1.0.0.1.1393561416 LLVM-GCC: build 2336 Clang: 3.1 build 318

Checking my clang executable:

$ /usr/bin/clang --version Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)

$ /Library/Developer/CommandLineTools/usr/bin/clang --version Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)

So it appears Command Line Tools didn't install clang (and perhaps other executables) into /usr/bin? I checked my other laptop (w/ Mavericks), and /usr/bin/clang is version 5.1.

So I'm guessing this is the problem? I've tried to reinstall Command Line Tools as sudo, but now it won't let me install again (says software isn't currently available).

Can anyone help me with this? I've spent hours on it now, but can't find a solution.

Thanks

Mac, Mac OS X (10.5.6)

Posted on Mar 29, 2014 8:36 AM

Reply
15 replies

Mar 31, 2014 3:45 AM in response to chrisyunker

Last login: Mon Mar 31 04:50:39 on console

xew ~/$:ls -l /usr/bin/clang

-rwxr-xr-x 1 root wheel 14224 Oct 23 11:08 /usr/bin/clang

xew ~/$:which clang

/usr/bin/clang

xew ~/$:clang -v

Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)

Target: x86_64-apple-darwin13.1.0

Thread model: posix

xew ~/$:

My understanding is that in Mavericks the programs in /usr/bin associated with command line tools are shims or stubs that are controlled by the Xcode commands like xtool-select.

Mar 30, 2014 12:31 PM in response to chrisyunker

Digging more into xcode-select -p path. If I look in that directory, it appears that the command line tools get copied there. So that seems correct.


$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/clang -v

Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)

Target: x86_64-apple-darwin13.1.0

Thread model: posix


The question still remains as to why they're not getting copied to my /usr/bin/. For Xcode applications, I think I'm fine. My problem is I'm using home brew, and it still uses what's in /usr/bin/.


Just curious, what is the output of:


ls -l /usr/bin/clang


I'm curious if it's a link or an executable.


Thanks for everyones help on this.

Mar 31, 2014 4:06 AM in response to chrisyunker

BTW, I installed Xcode 5.1 from the Store, but have never run xcode-select --install. Here is the verbose output from a clang.


xew ~/$:clang -v -o hello main.c

Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)

Target: x86_64-apple-darwin13.1.0

Thread model: posix

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/../lib/clang/5.1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk -fdebug-compilation-dir /Users/xew -ferror-limit 19 -fmessage-length 100 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/zf/d5vqmmtn5mq7h6766jtlkrvr0000gn/T/main-353995.o -x c main.c

clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.1.0

ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /SDKs/MacOSX10.9.sdk/usr/local/include"

ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /SDKs/MacOSX10.9.sdk/Library/Frameworks"

#include "..." search starts here:

#include <...> search starts here:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/../lib/clang/5.1/include

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/include

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk/usr/include

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk/System/Library/Frameworks (framework directory)

End of search list.

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain /usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/ SDKs/MacOSX10.9.sdk -o hello /var/folders/zf/d5vqmmtn5mq7h6766jtlkrvr0000gn/T/main-353995.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a

xew ~/$:

Mar 31, 2014 6:26 AM in response to chrisyunker

LIBMACLAPcaggiano ~ % ls -l /usr/bin/clang

-rwxr-xr-x 1 root wheel 14224 Oct 22 19:01 /usr/bin/clang


LIBMACLAPcaggiano ~ % ls -l /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ usr/bin/clang

-rwxr-xr-x 1 root wheel 36866064 Mar 13 08:11 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/u sr/bin/clang


LIBMACLAPcaggiano ~ % xcode-select -p

/Applications/Xcode.app/Contents/Developer


Looking at the size difference between clang in /usr./bin and in the Xcode.app bundle xnav is correct in that the file in /usr/bin is a stub that redirects to where the xcode-select path points.


So the question in your case is is the clang in /usr/bin on your system a full executable or a stub pointing to the wrong place. And if it is a full executable why is it there.


I installed the command line tools from within Xcode never used xcode-select or the dmg file. Not sure if that has anything to do with it.


I would remove clang from /usr/bin if it is there and try the install from Xcode, see if that puts in the stubs.


Also have a look at the man page for xcode-select, under the Files section. After a long list of the BSD tools in /usr/bin there is this

Runs the matching BSD tool from with the active developer directory.

Mar 31, 2014 7:42 AM in response to Frank Caggiano

Thanks for the feedback. I was noticing the same thing on my good laptop. The /usr/bin/clang size was small and likely a shim. Thanks for verifying that.


On my bad laptop, the /usr/bin/clang appears to be the full executable:


$ ls -lt /usr/bin/clang

-rwxr-xr-x 1 root wheel 22985632 May 18 2012 /usr/bin/clang


Thanks for the idea, I might try the re-install of Xcode after moving the /usr/bin/clang out of that dir. I already tried that with CommandLineTools pkg and that didn't work.


Given I seem to be the only person with this issue, I'm not looking at re-imaging Mavericks. At this point, it may be less time. Also, even if I fix this, it may be a symptom of a larger issue.


If I do try that, I'll respond to this thread with the results. Or if I find out any more information on this.


Thanks again for the help.

Mar 31, 2014 8:01 AM in response to Frank Caggiano

Looking at the xcode-select man pages and things are making more sense. It appears 10.8 installed the full binaries, where as 10.9 installs shims. According to this post, if you overwrite the shims with executables, then they will fail to be upgraded.


http://nathancahill.github.io/installing-homebrew-on-mac-osx-mavericks/ (See top post by Nathan Cahill)


So I think something must have happened to this image to do that.

Mar 31, 2014 8:20 AM in response to Frank Caggiano

Ugh, sorry, I wrote the wrong name. I meant the top post by Daniel Dunbar.


Yes, totally agree with you. This is Daniel Dunbar's post basically says. Additionally, he says, once you overwrite the shims with executables, you're screwed since the xcode-select will no longer update them.


This is exactly what I think happend to the image I got. It's supposed to be fresh image with necessary IT packages on top (encryption, etc), but I think something must have happend. I'm asking for a new image from IT.

Command Line Tools installs the latest version of clang (and others) in /Library/Developer/CommandLineTools/... but not in /usr/bin/

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.