Revert "libcrypto: compile all PIC objects with -DOPENSSL_PIC"
This commit broke the build with some build options.
Some validation needs to be done to confirm that moving the preprocessor
argument to `secure/lib/libcrypto/Makefile.inc` works without breaking
the build, but revert for now until a `tinderbox` run can be done with
the change.
PR: 293934
Reported by: Jenkins, Trond Endrestøl
This reverts commit 14b9955e57cc28b61e785165b9effcbe620edb46.
wasi: consistently use the wasm32-wasip1 triple
The WebAssembly community have reclaimed wasm32-wasi, without suffix,
for a future WASI 1.0 standard. The first version of WASI, 0.1, is
now wasm32-wasip1 in triple form, WASI 0.2 is wasm32-wasip2, etc.
Starting LLVM 22 the non-suffixed form is deprecated, aligning with
Rust and Go:
https://github.com/llvm/llvm-project/issues/165344https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets/
The Mozilla build system's WASI checks always pass -Werror so
configure fails when the non-suffixed target/triple is passed using
LLVM 22:
Using wasi sysroot in /usr/local/share/wasi-sysroot
checking for the wasm C compiler... /usr/local/bin/clang22
checking whether the wasm C compiler can be used... yes
checking the wasm C compiler version... 22.1.0
[31 lines not shown]
databases/proxysql: Update to 3.0.6
- The previous commit actually updated us to 3.0.5 as upstream uses
the 3.0.6 tag as the start of 3.0.6 and v3.0.6 as the actual release.
Makefile.inc1: Don't force LLVM_BINUTILS off for cross-tools
Because of this setting we were still using ELF Tool Chain tools for
buildworld. The sets of binary utilities are largely equivalent and
this went unnoticed after commit 1cae7121c667 ("Enable LLVM_BINUTILS
by default").
This was discovered recently because ELF Tool Chain objcopy produces
standalone debug files without phdrs and this caused an issue with a
3rd party ELF parser [1]. Remove the forced setting so that we use
LLVM's binutils to build the system.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33876
Re-commit after fixing a bootstrapping issue with LLVM binutils (in
17494c6e6b7d "build: Boostrap LLVM_BINUTILS for cross-tools").
Reviewed by: imp, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55650
tpm: fix multi-threaded access with per-open state
The TPM driver currently has a single buffer per instance to hold the
result of a command, and does not allow subsequent commands to be sent
until the current result is read by the same OS thread that sent the
command, with a timeout to throw away the result after a while if the
result is not read in a timely fashion. This has a couple problems:
- The timeout code has a bug which causes all subsequent commands to
hang forever if a different OS thread tries to read the result
before the OS thread which sent the command, and the OS thread
which sent the command never tries to read the result.
- Even if the first problem is fixed, applications expect to be able
to read the result from a different OS thread than the OS thread
which sent the command. The particular case that we saw was a go
application where the go runtime scheduled the goroutine which read
the result to a different OS thread from one where the goroutine
that sent the command ran, and there's no way to force these to
[11 lines not shown]
