On Jan 28, 2015, at 5:58 PM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> Really now, even if that's true for the other stuff in there, it > shouldn't be for libclang Says who? Apple can reserve that particular library for internal use if it wants. (This doesn't mean that you *cannot* use it, it means that it's a *bad idea* to use it.) > Or else Apple does do "secret" things with its clang version ... I expect Apple does make its own modifications to the compiler it ships. They don't even call it "Clang". % /usr/bin/clang --version Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix % /opt/local/bin/clang-mp-3.7 --version clang version 3.7.0 (trunk 226372) Target: x86_64-apple-darwin14.1.0 Thread model: posix In any case, this has nothing to do with "secrecy"; it's about expectations of support and stability. The vendor can change a "private" ABI/API whenever it feels like, so it's a poor idea to rely on it. The libraries in XcodeDefault.xctoolchain aren't even versioned. >> Neither the Xcode SDKs nor the CLT contain those libraries, so I expect > > Eh? The CLT have libclang in /usr/lib. What? % ls /usr/lib/libclang* zsh: no matches found: /usr/lib/libclang* Are you sure your library is from the CLT? What does `pkgutil --file-info` say about it? > That library is of course only useful code that uses functionality clang > provides. Exactly what kdev-clang does: it provides a clang-based C/C++ > parser. You can compare it to the debugger library for which lldb is a > front-end that could be replaced by a graphical front-end, or one that looks > and feels like gdb. I know what libclang is. None of this means that it's wise to utilize a copy of libclang that is pretty clearly not intended for public use. vq _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev