On Wed, Oct 07, 2026 at 08:39:13PM +0200, Thomas Dettbarn wrote: > Having a quick look at the asterisk build 22.log... > > http://build-failures.rhaalovely.net/riscv64/2026-09-27/telephony/asterisk/22.log > > > Do you know why the pidf_lo_test.o, pidf_to_eprofile.o, eprofile_to_pidf.so > files are are the only ones being linked with the -melf64lriscv parameter? Because that's what the port specifies. grep -R LLD telephony/asterisk > (They are the ones ending in ld: error. > > > Looks as if there is some confusion with the RISC-V targets. Sometimes > the makefile thinks it is doing a crosscompile, sometimes it knows it is > a native compile. I don't think it's some cross-compile confusion, my previous email gave an explanation for the behavior. There's a diff to fix the ld.lld(1) problem on tech@. -- jca
OpenBSD Mail Box
BTC:1BsNfN6m7xtT4PqDb9jJHnDDFBb38zS9Yi
Wednesday, October 07, 2026
Re: riscv64 bulk build report
Having a quick look at the asterisk build 22.log... http://build-failures.rhaalovely.net/riscv64/2026-09-27/telephony/asterisk/22.log Do you know why the pidf_lo_test.o, pidf_to_eprofile.o, eprofile_to_pidf.so files are are the only ones being linked with the -melf64lriscv parameter? (They are the ones ending in ld: error. Looks as if there is some confusion with the RISC-V targets. Sometimes the makefile thinks it is doing a crosscompile, sometimes it knows it is a native compile. Thomas On 10/7/26 18:37, Jeremie Courreges-Anglas wrote: > On Wed, Oct 07, 2026 at 10:48:19AM +0100, Stuart Henderson wrote: >> On 2026/10/07 02:35, jca@wxcvbn.org wrote: >>> http://build-failures.rhaalovely.net/riscv64/2026-09-27/databases/postgresql-pllua.log >>> http://build-failures.rhaalovely.net/riscv64/2026-09-27/telephony/asterisk/20.log >>> http://build-failures.rhaalovely.net/riscv64/2026-09-27/telephony/asterisk/22.log >> ld: error: src/compat.o: file has conflicting properties: GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_FUNC_SIG >> ld: warning: src/compat.o: cannot link object files with different floating-point ABI from /usr/lib/crtbeginS.o >> >> Is LLD_EMUL set correctly for the arch? >> >> /usr/ports/infrastructure/mk/arch-defines.mk 77:_LLD_EMUL_riscv64 = elf64lriscv > AFAIK yes. There are two issues here: > > 1. an error that I have downgraded to a warning because the code is > too pedantic for its own good. Unfinished diff that went nowhere: > https://reviews.llvm.org/D106378 > > 2. compat.o has been generated with ld(1) and objcopy(1): > > ld -melf64lriscv -r -b binary -o src/compat.o src/compat.luac > objcopy --rename-section .data=.rodata,contents,alloc,load,readonly src/compat.o > cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new -Wendif-labels -Wmissing-format-attribute -Wcast-function-type -Wformat-security -Wmissing-variable-declarations -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-format-truncation -Wno-cast-function-type-strict -O2 -pipe -fPIC -DPIC -fvisibility=hidden -shared -o pllua.so src/compile.o src/datum.o src/elog.o src/error.o src/exec.o src/globals.o src/init.o src/jsonb.o src/numeric.o src/objects.o src/paths.o src/pllua.o src/preload.o src/spi.o src/time.o src/trigger.o src/trusted.o -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib -Wl,-Bdynamic -fvisibility=hidden src/compat.o -L/usr/local/lib -llua5.3 -lc > ld: error: src/compat.o: file has conflicting properties: GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_UNLABELED and GNU_PROPERTY_RISCV_FEATURE_1_CFI_LP_FUNC_SIG > ld: warning: src/compat.o: cannot link object files with different floating-point ABI from /usr/lib/crtbeginS.o > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > ld(1) itself is at fault, llvm-readelf -Wa on such an object file gives: > > Properties: RISC-V feature: ZICFILP-unlabeled, ZICFISS, ZICFILP-func-sig, <unknown flags: 0xfffffff8> > > which looks like junk. I have noticed this since months already but I > haven't bothered yet to go and find the root cause. >