Why does Homebrew report "couldn't understand kern.osversion `14.0.0'"?

Question

When I run brew -- config I get

HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/Homebrew/homebrew
HEAD: bc071fb5448628aea8f066bbc0f37b0ecb4f11ee
Last commit: 16 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: quad-core 64-bit haswell
OS X: 10.10.1-x86_64
Xcode: 6.1.1
CLT: 6.1.1.0.1.1416017670
couldn't understand kern.osversion `14.0.0'
GCC-4.2: build 5666
Clang: 6.0 build 600
X11: 2.7.7 => /opt/X11
System Ruby: 2.0.0-p481
Perl: /usr/bin/perl
Python: /usr/local/bin/python => /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/bin/ruby

even though my Xcode (on Yosemite) command line tools seem to be current (to be sure I re-ran xcode-select --install) and in the right place

/Applications/Xcode.app/Contents/Developer

according to xcode-select -print-path, my (only) gcc is

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

and the only issues according to brew doctor are

Unexpected static libraries:
    /usr/local/lib/libtclstub8.6.a
    /usr/local/lib/libtkstub8.6.a

However I have a couple suspicious things lying around, notably usr/bin/gcc-4.2, for which --version gives

couldn't understand kern.osversion `14.0.0'
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
...

and /usr/bin/i686-apple-darwin11-gcc-4.2.1, for which --version also gives

couldn't understand kern.osversion `14.0.0'
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)    
...

What does brew -- config's report of

couldn't understand kern.osversion `14.0.0'

mean? Is there something I should do about it?

A quick search indicates it's a problem with gcc and recent OS X versions. The gcc version listed here appears to be the XCode installed one though; can you show which gcc (path) this is? — , Jan 21 '15 at 13:36
I've only got one `gcc` (according to `which -a gcc`) at `/usr/bin/gcc`. I've [added details](http://stackoverflow.com/posts/28068383/revisions) to the question. — orome, Jan 21 '15 at 13:39
At a guess, since gcc has been abandoned by Apple in favour of clang, that may be a left-over gcc from an older OS X, and now that gcc doesn't work with the new OS X kernel anymore. Though then I don't understand the output of `gcc --version`. Or rather, why `brew --config` lists `gcc-4.2`. — , Jan 21 '15 at 13:54
Note: my OS X (10.8 though) doesn't show any `gcc` in `brew --config`, so I suspect there is a `gcc-4.2` somewhere on your path that homebrew is picking up. And that particular gcc may conflict with the current OS X kernel. — , Jan 21 '15 at 13:56
@Evert: I do have some suspicious 4.2s lying around (see [the update to my question](http://stackoverflow.com/posts/28068383/revisions)). What can I do about them (and why are they there)? — orome, Jan 21 '15 at 14:57
Did you upgrade OS X on this machine some time ago? I guess they're from an older installation. Since gcc isn't installed by default, an OS upgrade probably didn't remove them. Whether you can really safely remove them, I don't know, but the obvious thing would be to rename them (or move them in a backup subdir), so that they are out of your path, and homebrew won't find them. Very likely, your system (XCode, brew) will continue as usual, since they'll use the clang found on your system. — , Jan 21 '15 at 15:10
@Evert: I've upgraded/migrated a couple of times. At some point I also installed from [HPC](http://hpc.sourceforge.net) (for gfortran, but gcc might have been carried along); I had some [flaky directories lying around](http://stackoverflow.com/q/27946118/656912), which I removed a while ago (I tested putting them back as well, but that had no effect on this). Are there specific things I should rename or look for (beyond the two listed)? — orome, Jan 21 '15 at 15:15
The "leave them alone" advice in the answer to your linked question seems appropriate, except that homebrew may try and use that gcc and compilation will break. So, perhaps this is the time to get red of them in a safe way. I think HPC installs stuff in `/usr/local` instead, as was more or less evidenced in one of your [previous questions](http://stackoverflow.com/questions/27861808/are-there-obvious-sources-for-the-brew-doctor-warnings-im-seeing/27865394#27865394). Other than, I don't think there's much I can advice now. — , Jan 21 '15 at 15:23
@Evert: Yes, "this is the time to get red of them in a safe way": how do I do that ? (That would be an answer.) — orome, Jan 21 '15 at 18:02
@Evert: FWIW, for now `mv /usr/bin/gcc-4.2 /usr/bin/RENAMED-gcc-4.2` removes the error and the GCC-4.2 line from the output of `brew --config`; but I've no idea what other (negative) effects that might have. — orome, Jan 21 '15 at 18:12
Very likely none: XCode will use the newer clang; other programs will use whatever compiler you tell them to use, or whatever they found on your $PATH (if such a program/installation complains it can't find gcc, try first to tell it to use clang instead, and otherwise use homebrew to install a much more recent gcc like 4.9; don't revert back to 4.2). Programs that in the past were compiled with 4.2, will still find the corresponding libraries in `/usr/lib`, which is what they need; not the compiler itself. — , Jan 21 '15 at 22:18
@Evert: Cool. The comments sound like they could be rolled into an acceptable answer. — orome, Jan 21 '15 at 22:34
@Evert: Bumping: I think you have the answer, which I'd accept. — orome, Feb 25 '15 at 12:55

score 3 · Accepted Answer · answered Feb 26 '15 at 12:22

Did you upgrade OS X on this machine some time ago? I guess they're from an older installation. Since gcc isn't installed by default, an OS upgrade probably didn't remove or replace gcc and other XCode command line tools. Whether you can really safely remove them, I don't know, but the obvious thing would be to rename them (or move them in a backup subdirectory), so that they are out of your PATH. That way, homebrew will not find them and use the newer compiler (clang). Very likely, your system (XCode, brew) will continue as usual, since they'll use the clang found on your system.

The error you see, "couldn't understand kern.osversion '14.0.0'", is likely from the fact that this gcc was compiled against an older OS X kernel version, and the current one (Yosemite/14.0.0) is backwards incompatible with that.

I don't know exactly which compiler tools all get installed, but for just the offending gcc, you can do something like:

mv /usr/bin/gcc-4.2 /usr/bin/gcc-4.2-oldOSX10.9

(assuming this was installed on 10.9; possibly on an earlier version).

It's a bit unfortunate that an upgrade of XCode (or rather, a completely new version) doesn't check for older versions of the command line tools and removes those(*). Though understandably, Apple of course assumes that you don't use anything outside the normal XCode tools; they obviously won't support homebrew in such a way.

(*) perhaps it does, but if you skipped a version or 2, it may not go back that far in time checking for older versions.

I encountered the same issue. In my case, I had to run `brew uninstall apple-gcc42` which fixed the problem. — Sandeep M, Jul 01 '15 at 13:48
@SandeepM That's an interesting solution. But homebrew should stay out of `/usr/bin`, so my question would be whether your offending gcc was in `/usr/local/bin` instead. I guess the homebrew uninstall solution won't work for everyone, but it does show that Apple's gcc42 causes problems after updates. (the Homebrew `apple-gcc42` formula says: "This formula contains compilers built from Apple's GCC sources, build 5666.3".) — , Jul 02 '15 at 00:09
You're correct. In my case gcc42 was in fact in `/usr/local/bin`. — Sandeep M, Jul 03 '15 at 12:27

Why does Homebrew report "couldn't understand kern.osversion `14.0.0'"?

1 Answers1