Seems like the source archive for abcl 1.8.0 was replaced on 2020-10-30
on both common-lisp.net and abcl.org. Now using the new hash and
abcl.org for src.
Yosys now has their own official scheme for tagging unstable builds;
an automation robot appears from the darkness once every few hours,
bumps the version number, and disappears as silently as they came.
While Nix packages use a date-based version format for unstable
packages, many (most!) users of Yosys use an unstable version. And so
synchronizing the version of the Nix package with the repository version
is significantly less confusing to users. This also adds a safeguard to
ensure others don't forget to bump the version number correctly in the
future.
The testsuite also saw an overhaul (now parallel to help build time), so
some tweaks were needed to get it working again.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Build the llvm support libraries (libcxx, libcxxabi) from scratch
without using the existing llvm libraries. This is the same spirit and
similar implementation as the "useLLVM" bootstrap in llvm package
sets. Critically it avoids having libcxxabi provided by the cc-wrapper
when building libcxx, which otherwise results in two libcxxabi
instances.
$ otool -L /nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib
/nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.dylib:
/nix/store/vd4vvgs9xngqbjzpg3qc41wl6jh42s9i-libc++-7.1.0/lib/libc++.1.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/gmpwk5fyp3iasppqrrdpswxvid6kcp8r-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/3hn7azynqgp2pm5gpdg45gpq0ia72skg-libc++abi-7.1.0/lib/libc++abi.dylib (compatibility version 1.0.0, current version 1.0.0)
/nix/store/1nq94scbxs6bk7pimqhvz76q6cfmbv97-Libsystem-osx-10.12.6/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
Additionally move some utilities (clang, binutils, coreutils, gnugrep)
to the stage layers so they can be replaced before the final
stdenv. This should cause most of stage4 to be built from the
toolchain assembled as of stage3 instead of the bootstrap toolchain.
