Integer multiplications where both integers are less than 64-bit but the
multiplication was greater than 64-bit were handled using an int128_t
type on octeon, with inconsistent results. The simplest fix in this
case is to not use an int128_t type, and fallback to the default codepath.
I pushed a fix for this upstream, this backports that fix.
Problem discovered by the openssl-ruby tests
Initial debugging by tb@ and claudio@
Access to octeon thanks to bluhm@
Further debugging and fix by me
Testing by tb@ and visa@
OK tb@
Any Ruby distpatches are going to use these going forward, and it's
better to set these once in Makefile.inc instead of in the Makefile
for each version.
few changes since 1.11.1.1113, but all minor things:
- Fix directory context of -X:deps prep with transitive local deps
- Fix bug in TDEPS-213 change
- TDEPS-213 - Add -X:deps aliases to list available aliases
- TDEPS-226 - More nunanced error handling for s3 downloads
- Better error message when git url can’t be inferred
- Use tools.deps.alpha 0.14.1185
while here also get rid of the double NO_BUILD, once is enough!
except for Python-2.7, which stays with 8.5.
Make COMMENTs and DESCRs consistent with Tk.
Fix typo in 3.10/files/CHANGES.OpenBSD.
OKs and thanks to kmos@, sthen@.
Mostly mechanical, except for having to run ./boot per
https://gitlab.haskell.org/ghc/ghc/-/issues/21626
Removed the %n patches merged into the release. The ./configure patch
is no longer needed and wouldn't apply due to #21626 above.
OK kili@
- Use CFLAGS and CXXFLAGS instead of CMAKE_CXX_FLAGS and CMAKE_C_FLAGS.
- Use MODCMAKE_LDFLAGS instead of CMAKE_EXE_LINKER_FLAGS
- Fix broken builds with CMake 3.23
Update HOMEPAGE.
Remove three patch files thanks to upstream changes.
Remove one patch file not needed since 2017-12-14:
https://marc.info/?l=openbsd-cvs&m=151322225127141
Remove static library section from README; 8.5 only.
built on top of llvm sources (but without any of our patches), it
builds/bundles compiler-rt, libcxx and libcxxabi for the 'wasm32-wasi'
target to provide the wasi sysroot required to enable wasm sandboxing in
firefox.
with some inspiration from freebsd/pkgsrc/archlinux.
ok sthen@
WASI Libc is a libc for WebAssembly programs built on top of WASI system
calls. It provides a wide array of POSIX-compatible C APIs, including
support for standard I/O, file I/O, filesystem manipulation, memory
management, time, string, environment variables, program startup, and
many other APIs.
this is one of the requirements to enable wasm sandboxing for bundled
libraries in firefox via rlbox, cf https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/
ok sthen@
cargo on i386 still need upstream libz (statically build) and break at runtime
(assert) when linked dynamically with base libz.
found the hard way by sthen@
build on i386 failed, no package produced, so no bump.
