Using Xcode toolchain internals (Was: apple clang vs macports clang performance)

[Lawrence Velázquez]

On Jan 28, 2015, at 5:58 PM, René J.V. Bertin <rjvbertin at 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