Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Staging next #85664
Motivation for this change
Since 2.44_01, the behaviour for `check_lib` in their `Makefile.PL` has been "fixed" to fail when the `assert_lib` function fails to build the test. * toddr/XML-Parser@2bc1e90 Now, this wouldn't be so bad, since it's good to actually test what stuff is being compiled against. Except that *something* is wonky with the cross-compilation build-time Perl. ``` Undefined subroutine &File::Temp::mktemp called at inc/Devel/CheckLib.pm line 236. ``` As far as I know, this is a built-in function from Perl. * https://perldoc.perl.org/File/Temp.html Though, something *else* is wrong with `Checklib.pm`. Side-stepping the issue by (eww) shelling out to `mktemp`, we get these errors: ``` /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-armv7l-unknown-linux-gnueabihf-binutils-2.31.1/bin/armv7l-unknown-linux-gnueabihf-ld: assertlib_src1_0.553056903257133: file not recognized: file truncated collect2: error: ld returned 1 exit status -I/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-expat-2.2.8-armv7l-unknown-linux-gnueabihf-dev/include -L/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-expat-2.2.8-armv7l-unknown-linux-gnueabihf/lib -lexpat /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-armv7l-unknown-linux-gnueabihf-binutils-2.31.1/bin/armv7l-unknown-linux-gnueabihf-ld: assertlib_src2_0.262169388446154: file not recognized: file truncated collect2: error: ld returned 1 exit status Can't link/include C library 'expat.h', 'expat', aborting. ``` Meanwhile, the actual build, while building the library, seemingly has no issues building using those paths. `¯\_(ツ)_/¯`
This will switch the default TCP congestion control algorithm from new Reno to CUBIC. CUBIC is the default since Linux kernel 2.6.19 (see 597811ec167fa) and most (all?) distributions keep this default (e.g. Debian and Ubuntu). On NixOS the default was still new Reno because generate-config.pl changes TCP_CONG_CUBIC from y to m (since we try to build everything as a module by default). To check the active and available algorithms: $ sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic $ sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno Note: E.g. x86_64_defconfig sets TCP_CONG_CUBIC=y indirectly via CONFIG_TCP_CONG_ADVANCED=y (but CUBIC is also the default if set to no, see net/ipv4/Kconfig).
It appears that cairo's configure script, at least on MacOS but perhaps elsewhere, unconditionally enables xlib support, even if the library isn't present, which breaks the build on MacOS always (since x11 is disabled by default now). This explicitly passes `--disable-x11` if x11Support is set to false, which fixes the build for me.
"Not a lot of changes in this release, most are related to fixing output formatting and documentation."  File changes (additions/removals): +share/man/man8/tc-ets.8.gz +share/man/man8/tc-fq_pie.8.gz nix path-info -S: 5.5.0 51509616 5.6.0 51528680 : https://marc.info/?l=linux-netdev&m=158585608413591
They will be installed now and we can provide $HOSTCC for cross-compilation. New files: +lib/tc/experimental.dist +lib/tc/normal.dist +lib/tc/pareto.dist +lib/tc/paretonormal.dist Note: The distributions are generated in a reproducible way. Co-Authored-By: Benjamin Saunders <email@example.com>
Unfortunately, we need to emulate the system to get a real cache. Native version doesn’t know the right paths.
This prevents duplication in cross-compiled nixos machines. The bootstrapped glibc differs from the natively compiled one, so we get two glibc’s in the closure. To reduce closure size, just use stdenv.cc.libc where available.
- Needs to be like <cpu>-<os>-gcc. - Remove unneeded --enable-external-build flag This confuses the feature detection and is not needed for cross compilation anymore.
What's the reason for this condition @matthewbauer ? It looks to me that the logic is wrong and
The issue I hit was that if GDK_PIXBUF_MODULE_FILE isn't set, the gdk-pixbuf module wouldn't load at all after cross compiling. But if this is failing for you, it may be better to not have that case. I can just set a dummy package so modulePackages is non-null.