It's more useful to be able to "bless" an existing bottle to be used on
later OSs (e.g. where it cannot yet be built) than it is to have to
create a new, identical bottle just to have a different filename.
Xcode 8.1 added timingsafe_bcmp to string.h and libsystem_c.tbd,
and 10.12.1 added it to libsystem_c.dylib, but it is not present in
libsystem_c.dylib on 10.11.6 (15G1108).
It may appear in libsystem_c.dylib in a later 10.11 release or it may
be marked weak on 10.11 in a later Xcode release.
FixesHomebrew/homebrew-core#6344.
some build systems check ac_cv_search_clock_gettime instead of
ac_cv_func_clock_gettime so the former should also be set to "no"
libev.m4 unsets ac_cv_func_clock_gettime, but if ac_have_clock_syscall
is defined, it will leave ac_cv_func_clock_gettime alone:
http://cvs.schmorp.de/libev/libev.m4?view=markup#l23
A smarter form of 559cea7fa9.
Travis users can't force Travis to update 10.11 to Xcode 8, so this was murdering
builds left, right & centre.
Fixes https://github.com/Homebrew/brew/issues/1096 whilst still retaining the
point of the original commit. Also offers developers an opt-out so if we need
to test something on 10.11 with Xcode 7.x we can, etc.
This reverts commit a124680b189f50ebeb550845e3c0efd34db66247.
Will need to be smarter than this, since people can't force Travis to
update. I'm losing count of the amount of times Travis has forced a change
of plans around Homebrew this year.
Closes https://github.com/Homebrew/brew/issues/1096.
Not quite a mass replacement as I've used OS X and Mac OS X where
describing specific older versions and added compatibility methods
for things in the DSL.
The GNU Autotools tests for whether a given symbol is defined are
reliably coming to incorrect conclusions on 10.11 with the 10.12 SDK
in Xcode 8. This overrides its decisions by forcing the right answer
in superenv using ac_cv_func_* environment variables and setting them to
"no" on 10.11. The list of problematic symbols is from
grep 'weak$os10.11' MacOSX.sdk/usr/lib/system/libsystem_c.tbd
The experiment to add `-no_weak_imports` unconditionally has been a bit
of a failure. It's broken more than it's fixed and I don't think we can
have this as a default for Xcode 8.
Add `ENV.no_weak_imports` to be used by formulae authors and make
`ENV.no_weak_imports a no-op (for now).
We may reconsider this behaviour in future.
Issue Homebrew/homebrew-core#3727 suggested we set -no_weak_imports for
new versions of Xcode to ensure that e.g. building on 10.11 against the
10.12 SDK doesn't result in a situation where autotools thinks symbols
exist that don't actually exist on the current platform.
Further discussion in golang/go#16770 revealed that some packages
require weak imports to build normally.
