'sw_vers' on Linux

Hi,

Im getting the following output somewhere in the the configure/make process:

make[4]: Entering directory
`/usr/local/src/llvm/build/tools/clang/runtime/compiler-rt'
which: no sw_vers in
(/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
make[5]: Entering directory `/usr/local/src/llvm/llvm/projects/compiler-rt'

Just for neatness value, it might be a good idea to redirect the
(stderr) output of the 'which sw_vers' command to /dev/null, so that
this message wont show up on Linux.

Just my 2$

- John Smith.

Think that was fixed a while back, what version are you on?

-eric

# svn info
Path: .
Working Copy Root Path: /usr/local/src/llvm/llvm
URL: http://llvm.org/svn/llvm-project/llvm/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 180264
Node Kind: directory
Schedule: normal
Last Changed Author: rafael
Last Changed Rev: 180262
Last Changed Date: 2013-04-25 14:45:46 +0200 (Thu, 25 Apr 2013)

# clang --version
clang version 3.3 (trunk 179976)
Target: i386-pc-linux-gnu
Thread model: posix

Huh. I thought Bob/Daniel fixed this.

Bob?

(Note, I have not tried to duplicate)

-eric

Hi,

I could be completely wrong here, but...

the 'solution' might have been to use 'which sw_vers', without
realizing that this would produce an error on stderr when its not
found ?

Just my 2$

_ John Smith

Hi,

I could be completely wrong here, but...

the 'solution' might have been to use 'which sw_vers', without
realizing that this would produce an error on stderr when its not
found ?

Yes, I think that's what happened.

Does the version of "which" on Linux and BSD support the -s (silent) option? That would be slightly cleaner than redirecting to /dev/null.

Gnu '/usr/bin/which' on my Fedora 17 system does not. But why worry
about possibly non-portable options like '-s', when ">/dev/null 2&1"
will work on all *nix flavors ?

- John Smith

Hi all,

Yuck. The "which -s" thing wouldn't have worked anyway, since the current code is checking the output, not the exit status of the command. I committed a change in compiler-rt r180792 that should fix this.