MacVim compiles the Vim part using `/usr/bin/clang` and the GUI part
using Xcode. The Xcode portion always uses Xcode's own SDK and we have
no workable alternative. The Vim portion so far has been compiling using
a hybrid compilation environment, where it uses the SDK for most stuff
but picks up a bunch of library linker paths (including libSystem) by
virtue of Ruby's LDFLAGS. This hybrid compilation environment meant that
if the SDK headers referenced a symbol that the library itself didn't
have, this could produce link errors.
Previously we attempted to fix this by synthesizing an include path that
contained just the one header from Nix's Libsystem that referenced the
missing symbol, to get rid of the reference and allow linking to work
again, but this was very hacky and runs the risk of future Xcode SDK
changes producing the same errors with different headers, or of future
SDK versions expecting the intercepted header to contain a definition
that Nix's doesn't.
This new approach is to just clean up the compilation environment such
that the Vim portion is compiling against the Xcode SDK as well, by
sanitizing the LDFLAGS produced by the configure script so it stops
referencing Nix's versions of OS libraries. This means the resulting Vim
binary no longer depends at runtime on Nix for anything except the
scripting language support, but that's how it's been for the MacVim
binary all along anyway, and this approach should keep us insulated
against future Xcode SDK changes.
Xcode 11.4 has an updated sys/_types/_fd_def.h header that references a
new symbol from libSystem. This is a problem because we're using
`/usr/bin/clang` to compile the non-Xcode portion, and this pulls in
headers from Xcode's SDK. Somehow it's still linking to the Nix
libraries (I can't figure out where configure finds these to put into
`LDFLAGS` as we're not using the cc-wrapper). The end result is we get a
linker error where this new symbol can't be found at link time, even
though it's a weak import and isn't required at runtime.
Ideally we'd provide a full 10.12 SDK to `/usr/bin/clang`, but we can't
do that because even the DevSDK package we use for our 10.12 SDK doesn't
contain everything (in particular it's missing nearly all dylibs) so we
just get linker errors if we do that.
Instead we'll just do a horrible hack and provide an `-isystem` path to
a folder structure that contains only the 10.12 `sys/_types/_fd_def.h`
header. This avoids the new symbol without causing all the errors that
happen if we pull in the entire `${darwin.Libsystem}/include`.
We were adding this to the compilation of MacVim, but not to the
compilation of the separate Vim binary. We may not actually need it for
MacVim at all, but omitting it for the Vim binary meant our postInstall
phase would fail for some people.
Fixes#73514
This allows full filesystem access except for Homebrew. This is because
we don't know where Xcode will be installed so we can't just whitelist
it and its dependencies.
This fixes several Xcode 11 incompatibilities with MacVim, including an
issue where it wasn't inheriting the deployment target correctly to
begin with.
It seems that /usr/bin/ibtool marks stdin/stdout/stderr as nonblocking,
which can cause the subsequent build phase to fail when it tries to
write to stdout. I don't know why this problem just started happening
for me, but preventing ibtool from inheriting fds fixes the problem.
Fix up the macvim package to build again, with the latest snapshot. The
patchfile has been recreated by manually reapplying all of the changes
from the old patchfile, and the other changes in here were figured out
by trial and error (such as the need to unset `LD`).
Also tweak the package to use python37 by default, and add an option to
go back to python27 if desired.
Disable Sparkle so the user isn't prompted to update a readonly package.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
