Combined with https://github.com/Homebrew/homebrew-test-bot/pull/247
this will test Homebrew's use of frozen strings in CI. After this we
will then enable it for Homebrew developers and eventually all Homebrew
users.
This reduces the deviation in compilation flags on a given OS between
users and between bottling/not bottling to provide a consistent
behaviour for debugging and support.
CMake tries to use Xcode if MACOSX_DEPLOYMENT_TARGET is set but that can
lead to build failures when SDKROOT isn't set. The CMake behavior at
minimum manifests as -isysroot spontaneously being set to the Xcode SDK,
which brew sometimes can't successfully fully unwind with its ENV hacks.
- atomic_write: close file before renaming to prevent error:
'Device or resource busy'
- ensure_writable: preserve executable bit
- new elf? and dynamic? methods
The GNU Autotools tests for whether futimens and utimensat are available
reliably come to incorrect conclusions on 10.12 with the 10.13 SDK in
Xcode 9. This overrides its decisions by forcing the right answer
in superenv using ac_cv_func_* environment variables and setting them to
"no" on 10.12.
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
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.
Switch to HOMEBREW_LIBRARY since HOMEBREW_LIBRARY_PATH already includes
"/Homebrew" and HOMEBREW_LIBRARY is less confusing.
Closes#530.
Signed-off-by: ilovezfs <ilovezfs@icloud.com>
Move some stuff formerly in `Library/ENV` around:
- Move `Library/ENV/$XCODE_VERSION` to `Library/Homebrew/env/super` as they are
all superenv wrappers and all symlinks to the same version. We never needed
the "separate shims for separate versions" functionality and it just adds
confusion.
- Move `Library/ENV/pkgconfig` to `Library/Homebrew/env/pkgconfig` to get more
things under `Library/Homebrew`
- Move `Library/ENV/scm` to `Library/scm` as these wrappers are not actually
used by or related to superenv (or stdenv) in any way.
In 0d189fae57
we completely removed `effective_sysroot`, which consequently left all the
`effective_sysroot`/usr/include calls pointing at `/usr/include`. This is wildly
problematic on systems where the Command Line Tools aren't installed because
`/usr/include` is not a default-created folder prior to CLT installation.
I'm unsure if `effective_sysroot` should still be mentioned in Library/Homebrew/extend/ENV/super.rb
at all. If it can be deleted, feel free to do that without waiting for me to review.
This seems to fix:
* https://github.com/Homebrew/homebrew-core/issues/2991
* https://github.com/Homebrew/homebrew-core/issues/2986
* https://github.com/Homebrew/homebrew-core/issues/2962
