<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Great news, I figured out the problem.<div><br></div><div>It appears there is a bug in ccache from Macports. "cc" and "c++" point to different compilers. I filed a bug a couple of weeks ago and forgot about it. Here is the bug report for those who are interested: <a href="https://trac.macports.org/ticket/38183">https://trac.macports.org/ticket/38183</a><div><br></div><div>The old CMakeCache was created before I installed ccache which explains why it works when I try it to compile ITK with it.<br><div><br></div><div>I confirmed this after installing a virtual machine, updating to 10.8.3 and noticing that ITK builds fine. Then I tried uninstalling ccache in my real machine and that did the trick.</div><div><br></div><div>Sorry for the false alarm folks and thanks Sean for verifying that ITK builds on your 10.8.3 configuration.</div><div><br></div><div>Regards,<br><div><br><div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Ho Cheung</div><div>Research Assistant</div><div>Bio-Image Analytics Laboratory - University of Houston</div><div>(775) 388-2368</div></div></div></div></div></div></div></div></div><br class="Apple-interchange-newline"><br></div><div><div>On Mar 22, 2013, at 9:53 PM, Ho Cheung <<a href="mailto:hocheung20@gmail.com">hocheung20@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><blockquote type="cite">The Xcode update very likely comes with a slightly newer clang.<br></blockquote><br>Apparently, when I ran the compile yesterday I discovered that I was still using the "Xcode Command-Line Tools" that came with Xcode 4.6 instead of 4.6.1, so I don't think this is solely a compiler issue. Here's what clang -v had:<br><br>Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)<br>Target: x86_64-apple-darwin12.3.0<br>Thread model: posix<br><br>Here's what the new clang has right now:<br><br>Apple LLVM version 4.2 (clang-425.0.27) (based on LLVM 3.2svn)<br>Target: x86_64-apple-darwin12.3.0<br>Thread model: posix<br><br><blockquote type="cite">It doesn't seem to reproduce on Rogue7, but a notable difference there is that I use my own build of clang trunk from their svn, I don't use the clang Xcode includes, but I do use the system headers and C++ library from Xcode.<br></blockquote><br>As I understand it, Apple doesn't just take the clang sources and compile and release it, I've read somewhere they pick and choose pieces from all over the svn to suit their purposes.<br><br><blockquote type="cite">10.8.2 -> 10.8.3 is likely unrelated.<br></blockquote><br>Getting stranger and stranger. I'll start installing a Mountain Lion virtual machine tonight to investigate whether I can reproduce this.<br><br><blockquote type="cite">What version of CMake are you using? Rogue7 uses 2.8.11rc1.<br></blockquote><br>My mac is running 2.8.10.2.<br><br><blockquote type="cite">I've started an experimental build on Rogue7 with Xcode's clang.<br></blockquote><br>Excellent. Please let me know how it goes.<br><br>Regards,<br><br>Ho Cheung<br>Research Assistant<br>Bio-Image Analytics Laboratory - University of Houston<br>(775) 388-2368</blockquote></div><br></body></html>