When building with Xcode 8 beta (on my system at least), clang produced the following warning:
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9
It appears clang will link with libstdc++ if present by default instead of libc++. This was verified using `otool -L bundles.dylib` which produce the following output prior to this change.
bundles.dylib:
@rpath/bundles.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/OakSystem.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/io.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/plist.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/regexp.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/scope.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/text.dylib (compatibility version 1.0.0, current version 1.0.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
With this change the output is now:
bundles.dylib:
@rpath/bundles.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/OakSystem.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/io.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/plist.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/regexp.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/scope.dylib (compatibility version 1.0.0, current version 1.0.1)
@rpath/text.dylib (compatibility version 1.0.0, current version 1.0.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
With the boost thread helper we have to statically link to the boost libraries, which on most system is built against the latest version of the OS (instead of our current target 10.7). This doesn't seem to be an actual problem, but newer versions of clang issue warnings about it.
The new version of clang (Apple LLVM version 6.1.0) as shipped with Xcode 6.3, disabled TLS. According to http://clang.llvm.org/cxx_status.html, in order to support `thread_local`, the C++ runtime library from g++-4.8 or later is needed.
For now, we can use the boost `thread_specific_ptr`. This is probably a reasonable solution since 1) it should be portable with old and future versions of (Apple's) clang and 2) requires no additional dependencies.
This was just mirroring the last part of our version number so redundant and it wasn’t monotonically increasing as we switched from alpha.n → beta.1 (with n > 1), so it probably did more harm than good.
Set the `capnp_prefix` variable when calling ./configure.
E.g. build and install cap’n’proto in $HOME/build:
./configure --disable-shared --prefix="$HOME/build"
make -j6 check && make install
Then configure TextMate to find it there:
capnp_prefix="$HOME/build" ./configure
This option was removed in revision 191551 of clang (Sep 27, 2013).
Property synthesizing seems to now be default, it’s unclear to me what revision of clang made the behavior default, but since we require a fairly recent version for other things (like Cap’n’proto) I don’t think this change will cause a problem.
@executable_path is the originally-executed program, whereas @loader_path is the program that caused the load to occur (e.g. a Quick Look generator). @rpath can be changed at link time — a QL generator can specify a value that points to the enclosing app bundle’s Frameworks directory.
This is for oniguruma and ideally we would set this only for the oniguruma target, but then we need special precompiled headers for that target, so this is a practical way to achieve the goal (there are no other C sources in the build tree).
I never understood what this option was good for and now it gives a warning about being unused during compilation (even though it was set only during linking).
Basically libraries referenced indirectly will be setup as a requirement of the target and this option strips that. Doesn’t really matter, but enabling it rather than deleting the line (which was previously commented).
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
