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.
AddressSanitizer and ThreadSanitizer (https://github.com/google/sanitizers) are projects initially developed by Google Inc. Both tools consist of a compiler module and a run-time library. The sources of the run-time library for these projects are hosted at https://github.com/llvm/llvm-project in the following directories: compiler-rt/include/sanitizer compiler-rt/lib/sanitizer_common compiler-rt/lib/interception compiler-rt/lib/asan compiler-rt/lib/tsan compiler-rt/lib/lsan compiler-rt/lib/ubsan compiler-rt/lib/hwasan Trivial and urgent fixes (portability, build fixes, etc.) may go directly to the GCC tree. All non-trivial changes, functionality improvements, etc. should go through the upstream tree first and then be merged back to the GCC tree. The merges from upstream should be done with the aid of the merge.sh script; it will also update the file MERGE to contain the upstream revision we merged with.