vasilito
48a924c561
The libredox 0.1.19 / redox_syscall 0.9.1 bump left 45 recipe lockfiles pinning libredox 0.1.18+rb0.3.1 and redox_syscall 0.9.0+rb0.3.1. The cookbook builds with --locked, so every affected recipe died with error: cannot update the lock file .../Cargo.lock because --locked was passed to prevent this which is what took out redox-driver-sys -- and with it every Red Bear driver -- during the redbear-full build. Regenerating the fork lockfiles was not enough; the recipes that consume the forks as path deps carry their own. This is step 6 of local/docs/FORK-BUMP-PATCHING-POLICY.md applied to the recipe layer. Also drop the hardcoded GCC version in recipes/libs/libstdcxx-v3: the literal include/c++/13.2.0 stopped resolving the moment the cross toolchain moved to 16.1.0, leaving -I pointing at a directory that does not exist. Now resolves the newest installed C++ header directory and fails loudly if there is none. Same failure class as the hardcoded 13.2.0 in mk/prefix.mk. Note: a few recipe-level Cargo.lock files (redox-driver-pci, cpufreqd, redbear-acmd/-ecmd/-ftdi) sit beside a recipe.toml whose [source] is path = "source", so they are not build inputs; redox-driver-pci's even references a redox-driver-core/Cargo.toml that does not exist. They are left alone rather than given meaning they do not have. redox-driver-sys now cooks clean.
The files in this directory where noted are part of the DRuntime and Phobos library. DRuntime is the low-level runtime library backing the D programming language, hosted at https://github.com/dlang/druntime/. Phobos is the standard library for the D Programming Language, hosted at https://github.com/dlang/phobos/. The following sources and directories are part of DRuntime: libdruntime/core/ libdruntime/gc/ libdruntime/gcstub/ libdruntime/object.d libdruntime/rt/ The following sources and directories are part of Phobos: src/etc/ src/index.d src/std/ To report a bug or look up known issues with the runtime or standard library please visit the issue tracker at https://issues.dlang.org/. All changes to either of these libraries should go through the upstream repository first, then merged back to GCC.