Monthly Archives: February 2014

Apple hijacks Unix headers into Xcode in Mavericks

I am currently taking a class on Unix systems programming. While following along with lecture, the professor stated that almost always the header files needed for our type of work are located at /usr/include. However, that directory does not exist on my brand new Mavericks MacBook Pro. I have learned (after much searching the web) that the header files are now here:


After doing some more research, I found that to get those Unix header files back into /usr/include, one has to install Xcode’s command line tools. But, in order to get those, one has to be a registered member on Apple’s developer website. Not necessarily a paying member, but registered.

I was once a paying member for Apple’s developer tools but I gave it up because I was not actually using everything that was made available. My focus changed and the annual $99 was going to waste. In fact, because of that and that Apple has so much of their Cocoa documentation available externally for free, my need to log into their website has decreased over time to my not touching it in over a year. Now I am jumping through the hoops to figure out which account I was using and what was the password, but that is turning out to be harder than expected for a variety of reasons on Apple’s side, the servers not propagating my Apple ID resets to the developer site being one of them. Yes, I should have done a better job of recording my information, but a simple password reset shouldn’t be this hard either. At this point, I will likely just create a new account solely for getting me what I need.

I have no idea when Apple hijacked the header files, and i can understand the logic and convenience of doing so for tool updates, but knowing what little I do about Unix, hijacking seems to be anathema to the Unix culture. Apple has made my morning nothing but hassle trying to get this fixed and I will have an assignment due soon. So, cheers for that, Apple.

UPDATE: I wound up creating an account solely for the developer account, and it was, as expected, faster and easier than mucking about with a bunch of password resets. Once I did that, getting the command line tools was not straightforward though not hard (Xcode > Open Developer Tool > More Developer Tools… which then kicks you over to a downloads page on the developer website, with registration required for access).

As for my comment about the new default header location being anathema to Unix, I realize now that’s not necessarily true. If anything, Apple can do whatever they want with their distro. But the fact remains based on everything I have read so far that there are some clear expectations about there things ought to be and the header file location is one of them. But at least now I can establish a workflow where I can use the muscle of Xcode to develop and then confidently test outside before submission.