This fixes a couple of problems:
* Lua 5.1 doesn't have SYSLIBS, so wasn't being linked with any
libraries.
* SYSLIBS doesn't include -lm, so we had to add that manually to
pkgconfig. LIBS includes -lm, so we don't need that hack any more.
This patch was removed in 34f8d7e15a ("lua: one dso patch to rule
them all"), and the reference to it in lua5_4 was removed at the time,
but it seems to have found its way back somehow (probably through a
merge?).
(cherry picked from commit 5b278213a2)
This reverts commit 537a1940e8.
This patch was deliberately removed in 34f8d7e15a ("lua: one dso
patch to rule them all"). The correct fix is to remove the reference
to it that was reintroduced, rather than re-adding the patch.
One instance of this error/warning comes up during the build.
According to the comment in the code they know what they are doing,
so this can be ignored.
I am taking the non-invasive parts of #110914 to hopefully help out with #111988.
In particular:
- Use `lib.makeScopeWithSplicing` to make the `darwin` package set have
a proper `callPackage`.
- Adjust Darwin `stdenv`'s overlays keeping things from the previous
stage to not stick around too much.
- Expose `binutilsNoLibc` / `darwin.binutilsNoLibc` to hopefully get us
closer to a unified LLVM and GCC bootstrap.
The transmission conflict was non-trivial:
- libbrotli added to apparmor rules <1bdda029cd>
- apparmor rules rewritten <b280e64078>
Chosen the rewrite and verified that brotli is part of the rule set generated by `apparmorRulesFromClosure`.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
