Majority of packages with a version script have broken version scripts,
this will likely result in us adding this flag to many packages. To keep
things simple, just add it as a default.
Since a0b4b85bfa ("llvm: Avoid cross compiling if the build platform
can execute host binaries"), the flags to get a working
llvm-config-native are not used when the build platform can execute
host binaries, resulting in a broken llvm-config-native, and therefore
a broken mesa, but since build can execute host, we don't need a
separate llvm-config-native at all — we can just use the normal
llvm-config.
Fixes: a0b4b85bfa ("llvm: Avoid cross compiling if the build platform can execute host binaries")
This function was removed in Python 3.12 and seems to only be used in
LLVM 13, despite the Python file this is used in being present in
LLVM 12 and 14. The merge_archives.py file was removed in LLVM 15.
LLDB expects to find the location of `bin` relative to `lib`. Patching
it to know the location would cause a cycle between the `out` output and
the `lib` output, so combine the two on Darwin.
Fixes https://github.com/NixOS/nixpkgs/issues/252838.
update code to not assume that x64 darwin uses sdk 10.12. These changes
want to reach into apple_sdk.sdk to grab a header file which is only
required for sdk 10.12.
Native builds on nixpkgs FreeBSD always use llvm's libc++ as the
C++ standard library, with libcxxrt and "libgcc" from the FreeBSD tree
providing lower level ABI functions.
However, the cross LLVM stdenv assumed that we wanted libunwind instead
of libgcc. As libgcc headers are already in FreeBSD's libc, some C++
functions failed with duplicate header errors.
Disable all references to libunwind in libcxx on FreeBSD and the LLVM
cross stdenvs for FreeBSD.
If building clang under clang, don't pass -Wno-maybe-uninitialized;
this is a gcc-only warning and clang emits a diagnostic for every TU
about the unknown warning flag.
Signed-off-by: Peter Waller <p@pwaller.net>
mesa.drivers is basically an implementation detail and should never be used
as a dependency of other expressions. It also no longer exists on Darwin.
mesa.osmesa is very niche and should generally be avoided.
mesa.libdrm is used in exactly one place and it's irrelevant there.
Most Linux distributions are enabling this these days and it does
protect against real world vulnerabilities as demonstrated by
CVE-2018-16864 and CVE-2018-16865.
Fix#53753.
Information on llvm version support gleaned from
6609892a2d68e07da3e5092507a730
Information on gcc version support a lot harder to gather,
but both 32bit and 64bit arm do appear to be supported
based on the test suite.
