Since bash's parameter expansion for uppercase creates invalid
identifiers in certain locales (like Turkish), it is more ideal
to use `tr` for locale-agnostic string substitution.
Additionally, if there is a `windres` but no `rc`, `RC<suffix>` is
defined to point to `WINDRES<suffix>`.
My justification is essentially what I wrote in
https://github.com/mesonbuild/meson/pull/15438. Microsoft recommends
`RC`, CMake only supports `RC`, and Meson now supports both. In
addition, CMake and Meson are fine with "reversed" usage like
`RC=windres` and `WINDRES=rc`, so this simple defaulting logic should be
fine.
as with glibcxxassertions, we don't yet have a nice mechanism
for deferring support decisions to the c++ library in use, so
for now at least enabling this hardening flag will cause
_LIBCPP_HARDENING_MODE to be defined on all compilers
During the Apple SDK revamp of #346043, cc-wrapper and bintools-wrapper
were modified to automatically add a fallback SDK if $DEVELOPER_DIR is
not set [^1]. However, because of the order of the && operands,
apple-sdk is always evaluated even when it's not needed.
Flip the && operands so we only trigger the evaluation when targeting
Darwin.
[^1]: 51755b0c00
The existing post-link-hook is in an unfortunate position since it does
not enable interposing the arguments of the compiler.
This is an RFC to add a hook which enables that.
Signed-off-by: Peter Waller <p@pwaller.net>
Old versions of libtool for OpenBSD insist on adding the `-t` flag to
ranlib, which updates the timestamp. llvm-ranlib does not support `-t`
and as no plans to do so [1], since it makes builds less reproducable.
OpenBSD upstream deals with this by patching ranlib to ignore the `-t`
flag [2].
Instead of writing patches for all LLVM versions or re-running `autoreconf`
on all packages that use libtool, we can wrap ranlib to ignore the flag.
[1]: https://github.com/llvm/llvm-project/issues/57129
[2]: https://github.com/openbsd/src/commit/d00990cc11fce25520b9dde416bb8cf50990e992
`-arch` in the cc/ld wrapper causes problems when specifying different
`--target` options, which would succeed except for the conflicting
`-arch` specifier.
Reverts fc0456bed1 and
b26e0bac8d
`-L` and `-I` are interpreted relative to the `$SDKROOT` by the
Darwin toolchain, so we have to avoid filtering out such paths in the
purity filter hacks in order to not break e.g. the .NET Core build
system. It’s also just the correct thing to do for the platform.
This reduces code duplication, makes the SDK variables available
earlier in the wrappers, and makes the behaviour between the two
wrappers more consistent.
This is basically harmless for the same reason as it is for Clang, and
lets us avoid doing wrapper hacks to fix things like the .NET build.
This reverts commit 4340a5addb.
Now that ld.so is symlinked into the libc derivation,
we can use it as a dynamic linker.
In my testing, OpenBSD does not have any issues with executing from
a symlinked ld.so.
Without this change, all Darwin platforms mangle to the same suffix
salt. That is normally not an issue because build = host should mean a
non-cross build, but it causes issues on Darwin with static builds
because `DEVELOPER_DIR_FOR_BUILD` and `DEVELOPER_DIR` will refer to
different SDKs but mangle to the same `DEVELOPER_DIR` with suffix salt.
The fix is to mangle static builds differently from non-static ones on
Darwin, which allows building for a static Darwin target on a
same-architecture Darwin host. This fix is applied only to Dariwn
because the issue does not appear to affect other platforms.
It is unusual to invoke a wrapped compiler without setting
`DEVELOPER_DIR`, but it can happen when a user adds a compiler to their
installed packages or when a package intentionally invokes the compiler
without an environment (such as the GHC binary packages).
Some compilers may know to check these paths when `SDKROOT` is set, but
it’s not assumed they do. `SDKROOT` is instead derived from the
`DEVELOPER_DIR`, and `NIX_CFLAGS_COMPILE` is set up with the sysroot and
necessary framework and include search paths.
This is some thing introduced in 2017 to work around a problem that
no longer seems to exist. Nothing uses it except its own test, which
these days passes even with the standard `clangStdenv`.
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
(adapted from commit 51f1ecaa59)
(adapted from commit 1743662e55)
When the linker signs a Mach-O binary, it sets a flag in the signature’s code directory indicating that the signature was generated by a linker. Tools such as `strip` and `install_name_tool` read this flag and will
update ad hoc signatures after they perform their modifications.
The updated l64 supports signing binaries automatically. Both the updated cctools and LLVM will check for the linker-signed flag and resign binaries they modify automatically when it’s present. Given that, use of postLinkSignHook is unnecessary and potentially harmful.
In particular, if the hook is used and an unwrapped `strip` or `install_name_tool` is on the user’s path, they will not automatically update an ad hoc signature. Instead, they will issue a warning and create a binary with a broken signature.
It is more robust to let the tools handled this since the only time a signature would not be linker-signed is when the user is manually invoking `codesign` (or another tool such as `sigtool` or `rcodesign`), which by nature of the invocation updates the signature to a valid one.
Since `strip` no longer needs to be wrapped for code-signing, binutils-wrapper now uses the GNU strip wrapper on Darwin.
Fixes https://github.com/NixOS/nixpkgs/issues/208951.
This changes ld-wrapper to use a temporary file for the response file
passed to ld instead of using process substitution.
ld64 does not handle long command-lines when reading from the response
file, which defeats the point of using a response file to handle long
command-lines. cctools-port was patched to work around this, but nixpkgs
is now using Apple’s source release directly instead of the port.
Since it’s preferable not to patch Apple’s release heavily (to reduce
the difficulty of updating to new versions and to match upstream’s
behavior), use the approach that was adopted in cc-wrapper to work
around issues with response files in newer versions of clang.
Related PRs (cctools-port):
- https://github.com/NixOS/nixpkgs/pull/213831
- https://github.com/tpoechtrager/cctools-port/pull/132
Related PRs (cc-wrapper):
- https://github.com/NixOS/nixpkgs/pull/245282
- https://github.com/NixOS/nixpkgs/pull/258608
Marcin Serwin