how about a port containing the missing bits from Apple's LLVM toolchain?

Lawrence Velázquez larryv at
Wed Jan 28 12:23:04 PST 2015

On Jan 28, 2015, at 2:22 PM, René J.V. Bertin <rjvbertin at> wrote:

> On Wednesday January 28 2015 10:56:32 Jeremy Huddleston Sequoia wrote:
>>> Would it at least be possible to expand on that. In other words, why?
>> There are no shipped libraries for you to link against for the headers
>> to be worthwhile.
> I see:
> /Applications/
> 2495822 17516 -rwxr-xr-x  1 bertin bertin 17935264 Nov 17 19:38 libLTO.dylib*
> 2495823 12472 -rwxr-xr-x  1 bertin bertin 12771056 Nov 17 19:38 libclang.dylib*
> 2495824   336 -rwxr-xr-x  1 bertin bertin   342096 Nov 17 19:38 libfunctionNameDemangle.dylib*
> I *think* that libclang is all that kdev-clang needs...

That directory looks like it's very much for Xcode's internal use only.

    % ls -1 $(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/lib

Neither the Xcode SDKs nor the CLT contain those libraries, so I expect
that they're not intended to be used by third parties. You should just
use the LLVM ports.

> quoth larryv:
>> Pre-release llvm-* ports enable +assertions by default. If you installed
>> llvm-3.4 before it was released
> I'm pretty sure that I checked that, and I upgraded to 10.9 just before
> 10.9.2 came out, i.e. when llvm was a stable release. All I can say now
> is that my surviving 10.6 install has this in the software archive:
> var/macports/software/llvm-3.4/llvm-3.4-3.4.2_0.darwin_10.x86_64.tbz2
> I suppose that file would have +assertions in its name if that variant
> had remained active, no?

It would, yes. It'd be useful if you could actually demonstrate the
performance gap you're seeing.


More information about the macports-dev mailing list