staging-next 2022-06-23 #178690
Merged
staging-next 2022-06-23 #178690
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
vcunat
commented
Jun 23, 2022
vcunat
commented
- workflow docs: nixos.org/manual/nixpkgs/unstable/#submitting-changes-commit-policy
- important job(s): hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
- jobset: hydra.nixos.org/jobset/nixpkgs/staging-next
- nix-review reports: https://malob.github.io/nix-review-tools-reports/
- previous staging-next: staging-next 2022-06-10 #177171
- Use `nixpkgs-fmt`. - Order attributes according to common convention. - Use `enableFeature` consistently.
- intltool was replaced by vanilla gettext avahi/avahi@3d5a0c6 - gtk2 and qt4 disabled by default avahi/avahi@f060abe - qt3 disabled by default avahi/avahi@6ae7148 - howl-compat was disabled by default 17 years ago avahi/avahi@16d9e30
Building `pkgsCross.aarch64-multiplatform.avahi` would fail in the past with:
checking for pkg-config... no
configure: error: pkg-config is required to install this program
To fix that, two independent workarounds were applied, each sufficient:
- 34e4d0f
- 65a5313
These days, it is more common to just add `pkg-config` to `depsBuildBuild`.
configure: WARNING: unrecognized options: --without-atf, --without-docbook-xsl, --without-idn, --without-idnlib, --with-randomdev, --with-ecdsa, --with-gost, --without-eddsa, --with-aes, --with-libcap
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Due to bootstrap tools getting purged from closure of libidn2.dev, a very large rebuild is caused.
Without this, building `libffi` would do something horrible when
natively targeting `armv5tel-linux` on an `aarch64-linux` machine using the
32-bit compatibility sub-mode:
```
$ nix-build --system armv5tel-linux -A libffi --check
[...]
checking build system type... aarch64-unknown-linux-gnu
checking host system type... aarch64-unknown-linux-gnu
checking target system type... aarch64-unknown-linux-gnu
[...]
$ file result/lib/libffi.so.8.1.0
result/lib/libffi.so.8.1.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped
$ nm result/lib/libffi.so.8.1.0 | grep ffi_call
U ffi_call
```
Correct arch-specific code wouldn't be built at all, with the resulting binary subtly broken.
Co-authored-by: Fabian Affolter <fabian@affolter-engineering.ch>
Makes for easier to read code imo, case-in-point there was a duplicate test for
`$p = -E` before. While doing this little bit of refactor I changed rest ->
kept because that makes more sense, rest sounds like its the rest of params
while kept says these are the params that we've kept.
I tested for no change in behavior using the following bash script:
```
reset() {
cInclude=1
cxxInclude=1
cxxLibrary=1
dontLink=0
isCxx=0
nonFlagArgs=0
params=()
}
parseParams() {
declare -i n=0
nParams=${#params[@]}
while (("$n" < "$nParams")); do
p=${params[n]}
p2=${params[n + 1]:-} # handle `p` being last one
case "$p" in
-[cSEM] | -MM) dontLink=1 ;;
-cc1) cc1=1 ;;
-nostdinc) cInclude=0 cxxInclude=0 ;;
-nostdinc++) cxxInclude=0 ;;
-nostdlib) cxxLibrary=0 ;;
-x)
case "$p2" in
*-header) dontLink=1 ;;
c++*) isCxx=1 ;;
esac
;;
-?*) ;;
*) nonFlagArgs=1 ;; # Includes a solitary dash (`-`) which signifies standard input; it is not a flag
esac
n+=1
done
}
for p in c S E M MM; do
reset
params=-$p
parseParams
[[ $dontLink != 1 ]] && echo "expected dontLink=1 for params:${params[@]}" >&2 && exit 1
done
reset
params=(-x foo-header)
parseParams
[[ $dontLink != 1 ]] && echo "expected dontLink=1 for params:${params[@]}" >&2 && exit 1
reset
params=(-x c++-foo)
parseParams
[[ $isCxx != 1 ]] && echo "expected isCxx=1 for params:${params[@]}" >&2 && exit 1
reset
params=-nostdlib
parseParams
[[ $cxxLibrary != 0 ]] && echo "expected cxxLibrary=0 for params:${params[@]}" >&2 && exit 1
reset
params=-nostdinc
parseParams
[[ $cInclude != 0 ]] && echo "expected cInclude=0 for params:${params[@]}" >&2 && exit 1
[[ $cxxInclude != 0 ]] && echo "expected cxxInclude=0 for params:${params[@]}" >&2 && exit 1
reset
params=-nostdinc++
parseParams
[[ $cxxInclude != 0 ]] && echo "expected cxxInclude=0 for params:${params[@]}" >&2 && exit 1
reset
params=-cc1
parseParams
[[ $cc1 != 1 ]] && echo "expected cc1=1 for params:${params[@]}" >&2 && exit 1
reset
params=-
parseParams
[[ $nonFlagArgs != 1 ]] && echo "expected nonFlagArgs=1 for params:${params[@]}" >&2 && exit 1
reset
params=bleh
parseParams
[[ $nonFlagArgs != 1 ]] && echo "expected nonFlagArgs=1 for params:${params[@]}" >&2 && exit 1
reset
params=-?
parseParams
[[ $nonFlagArgs != 0 ]] && echo "expected nonFlagArgs=0 for params:${params[@]}" >&2 && exit 1
exit 0
```
This enables users to make use of clang's multi-platform/target support without having to go through full cross system setup. This is especially useful for generating bpf object files, I'm not even usre what would a no-userland cross compile system tuple even look like to even try going that route. Fixes #176128
…ilation This is mostly the same patch applied to stdlib distutils, except rebased and reworked a bit. This fixes cross-compilation of Python packages with C extension modules now that setuptools uses bundled distutils.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Without the change build fails on upstream llvm-11 as:
duplicate symbol '_Cfp' in: ddev.o dfile.o
python3Packages.uharfbuzz: only add ApplicationServices if stdenv.isDarwin
Otherwise the builds started to fail since the last bump: https://hydra.nixos.org/build/181462581 https://hydra.nixos.org/build/181520558
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.