- Pass --with-multilib-list=m4,m4-nofpu for SH4 so the kernel can use
-m4-nofpu. Move libraries out of !m4/ multilib subdirectory in
postInstall before moveToOutput.
- Generate sysroot-suffix.h for SH4 in the standalone libgcc builder.
- Add linux-kernel.target = "vmlinux" and installTarget for SH4.
All changes scoped to isSh4 to avoid rebuilds on other platforms.
Rather than implementing this at the wrapper level (which has been
attempted but not merged in # 252310 and # 205031), configuring GCC
directly with --enable-default-pie is simple and matches mainstream
distribution practices. Packages that cannot build with PIE can
explicitly pass -no-pie when needed, and mostly already do
due to the prevalence of GCCs built with this flag.
Requires followup to decide what to do with "pie" flag.
Without the change the `pkgsCross.loongarch64-linux.stdenv` fails as:
In file included from /build/source/libgcc/../gcc/config/loongarch/loongarch.h:53,
from ../../.././gcc/tm.h:53,
from /build/source/libgcc/fixed-bit.c:48:
/build/source/libgcc/../gcc/config/loongarch/loongarch-driver.h:82:10: fatal error: loongarch-multilib.h: No such file or directory
82 | #include "loongarch-multilib.h"
| ^~~~~~~~~~~~~~~~~~~~~~
This started happening in `nixpkgs` after `gcc` was update from `gcc-13`
to `gcc-14`. `gcc-14` added new auto-generated `loongarch-multilib.h` in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=227b18f5d7616d6d34ac44836a8679de9b43c857
That broke fragile `libgcc` derivation in `nixpkgs`: the derivation
sidesteps normal `gcc` build flow and relies on build details quite
heavily by explicitly listing `gcc/` dependencies of `libgcc/` sources.
This change forces `loongarch-multilib.h` build which is a new
dependency of `libgcc` on `loongarch64`.
Closes: https://github.com/NixOS/nixpkgs/issues/380901
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
I observed this package to be a big red herring when people are searching
for the package they need if libstdc++ is missing: I observed this to
happen if you're either very new to packaging and don't know where it's
supposed to come from or if you package some binary program (or virtual
environment) and this library is missing.
The package is a subset of GCC 3.3 from 2005 and only needed for very
old proprietary software that cannot be recompiled where it's only
questionable if this is even appropriate to have in nixpkgs.
There's in fact one such package, unreal tournament 2004. As much as I
don't think that libstdcxx5 has a place in here, this also applies to
it. If people want to consume this, it should belong into an external
flake.
Until this happens, I'm sorry for https://www.youtube.com/watch?v=mXapt4GHt-s
In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
This is needed for gcc13 on many platforms due to errors like:
```
checking for library containing dlopen... (cached) none required
checking for -fPIC -shared... yes
configure: error:
Building GCC with plugin support requires a host that supports
-fPIC, -shared, -ldl and -rdynamic.
```
This commit minimizes libgcc's gccConfigureFlags, and -- importantly
-- includes the three flags needed in order to prevent
`inhibit_libc` from becoming active.
This commit restores the pkgs/development/libraries/gcc/libgcc
package, which was deleted by commit 9818d120be.
We need to be able to build libgcc separately from gcc in order to
avoid a circular dependency. Nixpkgs is unusual -- unlike any other
distribution, it cannot tolerate circular dependencies between
dynamically linked libraries. Because of this, upstream is
extremely unsympathetic to the trouble that the glibc<->gcc circular
dependency causes for us; if we don't solve it ourselves it will not
be solved.
`libgcc` is not usable as is and as a result no packages use it today.
`gcc.cc.libgcc` should provide the same library. But ideally it should
not be used at all as it's an implementation detail of `gcc` support
libraries.
Done with the help of https://github.com/Mindavi/nixpkgs-mark-broken
Tool is still WIP but this is one of the first results.
I manually audited the results and removed some results that were not valid.
Note that some of these packages maybe should have more constrained platforms set
instead of broken set, but I think not being perfectly correct is better than
just keep trying to build all these things and never succeeding.
Some observations:
- Some darwin builds require XCode tools
- aarch64-linux builds sometimes suffer from using gcc9
- gcc9 is getting older and misses some new libraries/features
- Sometimes tools try to do system detection or expect some explicit settings for
platforms that are not x86_64-linux
