On Jan 28, 2015, at 5:58 PM, René J.V. Bertin <[email protected]> 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
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
