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

Question

Level 1

9 points

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

Answer 1

r_kazak

Level 1

5 points

Mar 29, 2014 5:26 PM in response to chrisyunker

You could just 'mv' the file out of the way and see if reinstalling places the version you expect there?

Maybe it's a permissions thing? Both hosts are running Maverick?

Reply

Answer 2

Mar 29, 2014 7:17 PM in response to chrisyunker

Here I have

Pandora ~ % which clang

/usr/bin/clang

Pandora ~ % 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

Pandora
~ %

My /Library/Developer folder is empty. I did not do anything special during the install.

How did you install Xcode, via the App Store ?

Reply

Answer 3

r_kazak

Level 1

5 points

Mar 30, 2014 9:49 AM in response to chrisyunker

Yes I installed Xcode via iTunes. I copied the command line tools and installed the package separately.

https://developer.apple.com/downloads/index.action#

Reply

Answer 4

Mar 30, 2014 9:52 AM in response to chrisyunker

Check to see what xcode-select -p is showing and also if you have DEVELOPER_DIR set in your environment.

Reply

Answer 5

chrisyunker Author

Level 1

9 points

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

I tried moving /usr/bin/clang to a temp directory, then reinstalled the package:

commandline_tools_os_x_mavericks_for_xcode__march_2014.dmg. That still didn't install clang to /usr/bin.

$ xcode-select -p

/Applications/Xcode.app/Contents/Developer

DEVELOPER_DIR is not set in my environment

Should xcode-select be set to another directory?

Reply

Answer 6

chrisyunker Author

Level 1

9 points

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.

Reply

Answer 7

r_kazak

Level 1

5 points

Mar 30, 2014 5:40 PM in response to chrisyunker

I would imagine that they would be symlinked into those 'UNIX' paths. Maybe the symlinking is failing as the items trying to be linked already exist?

Reply

Answer 8

xnav

Level 5

7,089 points

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.

Reply

Answer 9

xnav

Level 5

7,089 points

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 ~/$:

Reply

Answer 10

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.

Reply

Answer 11

chrisyunker Author

Level 1

9 points

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.

Reply

Answer 12

Mar 31, 2014 7:53 AM in response to chrisyunker

Just rememebr if it works when you remove clang you will need to go back and do it for all the rest of the tools in /usr/bin also.

good luck

Reply

Answer 13

chrisyunker Author

Level 1

9 points

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.

Reply

Answer 14

Mar 31, 2014 8:10 AM in response to chrisyunker

His analysis sounds right but I don;t like his resolution. I think it would be best to get the stubs in /usr/bin and leave the actual tools in Xcode.app

Otherwise, at a minimum, every time you do and update or upgrade with Xcode or the tools you will need to go in and do the hack.

Reply

Answer 15

chrisyunker Author

Level 1

9 points

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.

Reply