Bug 281600
| Summary: | lang/rust failing to build on risc-v (again) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | dgilbert | ||||
| Component: | Individual Port(s) | Assignee: | Mitchell Horne <mhorne> | ||||
| Status: | In Progress --- | ||||||
| Severity: | Affects Many People | CC: | alfredo, asomers, dclarke, emaste, fuz, jrtc27, mhorne, mikael, pkubaj, riscv, tomek | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(rust) |
||||
| Version: | Latest | ||||||
| Hardware: | riscv | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
This is not a case of "again".
This is a situation where Rust will not build yet and has not been building for years.
There is a whole dialog on this all over the place ( AOTP ) on github :
https://github.com/rust-lang/rust/issues/89058
https://github.com/rust-lang/rust/issues/92466
Also opening and re-opening bugs over and over and over all on the
same topic really gets us nowhere.
Ranting on a maillist is just a much noise :
https://lists.freebsd.org/archives/freebsd-riscv/2024-September/000383.html
I am currently looking into the Rust sources and digging around
but the Holy Church of Rust may not care at all ... even if there were a patch.
I was under the impression that it did build for some sort period of time. Now, gtk3 requires librsvg-rust rather than librsvg (non-rust) ... meaning that you can't even build emacs. The key problem is that we don't support system calls removed with FreeBSD 13 on RISC-V as FreeBSD 12 did not support RISC-V. But Rust requires these to work. It was neither possible to convince the Rust team to bump their ISA requirements to FreeBSD 13, nor the RISC-V FreeBSD team to add COMPAT-12 support, so they issue remains unfixed. (In reply to Robert Clausecker from comment #3) Thank you for the critical information. This pretty much kills any reasons to keep running FreeBSD on RISC-V since the dependency tree with Rust will only grow larger. (In reply to Dennis Clarke from comment #4) Just add compat11 to your kernel config and build / install this kernel. (In reply to Mikael Urankar from comment #5) Which should be the default, given how important rust is for the ecosystem, but apparently ideological purity and elegance are more important than worldly things like working software. Maybe librsvg-rust can be reverted in order to avoid Rust dependencies? Maybe libsvg could be a metaport that will select librsvg-rust where rust works fine and libsvg-classic on RISC-V until ABI problems are resolved? Maybe COMPAT11 should be part of GENERIC configuration (on RISC-V?) because Rust depends on it? (In reply to Robert Clausecker from comment #6) I copied the GENERIC to SIFIVE-COMPAT11 and then : enceladus# pwd /usr/src/sys/riscv/conf enceladus# enceladus# grep -E 'COMPAT_FREEBSD1?' SIFIVE-COMPAT11 options COMPAT_FREEBSD11 # Compatible with FreeBSD11 options COMPAT_FREEBSD12 # Compatible with FreeBSD12 options COMPAT_FREEBSD13 # Compatible with FreeBSD13 options COMPAT_FREEBSD14 # Compatible with FreeBSD14 enceladus# This will take a few days. The SiFive Unmatched Rev B board is amazingly slow. Oh, also, I have already done a stop-start-curse cycle because I forgot this lovely LLVM/Clang gack : enceladus# diff -u lib/clang/llvm.build.mk.orig lib/clang/llvm.build.mk --- lib/clang/llvm.build.mk.orig 2024-09-14 16:22:27.086093000 +0000 +++ lib/clang/llvm.build.mk 2024-09-24 23:24:12.892557000 +0000 @@ -108,7 +108,7 @@ .if ${LINKER_TYPE} == "mac" LDFLAGS+= -Wl,-dead_strip .else -LDFLAGS+= -Wl,--gc-sections +LDFLAGS+= -Wl,--gc-sections,-m,elf64lriscv_fbsd .endif CXXSTD?= c++17 enceladus# Anyways ... we are looking at days and days before this completes. That should be *if* it completes a build. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Making progress here :
--------------------------------------------------------------
>>> World build completed on Thu Sep 26 13:33:39 GMT 2024
>>> World built in 133367 seconds, ncpu: 4, make -j4
--------------------------------------------------------------
More to follow. Eventually. Slowly.
Well ... here we are ... so very very slowly grinding along at hand crank single step speeds : load: 1.75 cmd: sh 2457 [nanslp] 136380.60r 1604.02u 3166.07s 2% 2520k mi_switch+0x15e $x.2+0x1a sleepq_catch_signals+0x288 sleepq_timedwait_sig+0x12 _sleep+0x21a kern_clock_nanosleep+0x1da sys_nanosleep+0x44 do_trap_user+0x1e0 cpu_exception_handler_user+0x72 [150rv64-latest] [2024-09-27_03h40m22s] [parallel_build] Queued: 72 Built: 56 Failed: 2 Skipped: 10 Ignored: 0 Fetched: 0 Tobuild: 4 Time: 1D:13:53:02 ID TOTAL ORIGIN PKGNAME PHASE PHASE TMPFS CPU% MEM% [02] 1D:10:10:18 lang/rust | rust-1.81.0 build 1D:10:01:13 5.96 GiB 16.5% 1% [1D:13:53:25] Logs: /poudriere/data/logs/bulk/150rv64-latest/2024-09-27_03h40m22s see that ? That is the amazing SiFive RISC-V Unmatched working with a COMPAT11 kernel for the last 37 hours at least. Very very slowly hand cranking the Rust build. Maybe by Monday we have the Holy Church of Rust built on RISC-V. Maybe. Are there patches, or is it all in the tree? (In reply to dgilbert from comment #11) If there will be anything that smells like a patch then I will post it here. Thus far the SiFive Unmatched is just slowly, painfully slow and tedious and grinding along. I am glad I put a hard drive activity led on that board just so I know it is doing something. From time to time it blinks. So here we are in day three of the lang/rust compile : ID TOTAL ORIGIN PKGNAME PHASE PHASE TMPFS CPU% MEM% [02] 3D:04:18:44 lang/rust | rust-1.81.0 build 3D:04:09:39 12.88 GiB 71.1% 3.3% Being curious I went looking at the logs where I see things are indeed bubbling along. Finally into something called stage1. The bootstrap is happening where I see this binary exists inside a jail : console# file /poudriere/data/.m/150rv64-latest/02/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo /poudriere/data/.m/150rv64-latest/02/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo: ELF 64-bit LSB pie executable, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), dynamically linked, interpreter /libexec/ld-elf.so.1, FreeBSD-style, with debug_info, not stripped console# console# readelf -delV /poudriere/data/.m/150rv64-latest/02/wrkdirs/usr/ports/lang/rust/work/bootstrap/bin/cargo ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: NONE ABI Version: 0 Type: DYN (Shared object file) Machine: RISC-V Version: 0x1 Entry point address: 0x865120 Start of program headers: 64 (bytes into file) Start of section headers: 49222768 (bytes into file) Flags: 0x5, double-float ABI, RVC Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 12 Size of section headers: 64 (bytes) Number of section headers: 46 Section header string table index: 44 Elf file type is DYN (Shared object file) Entry point 0x865120 There are 12 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040 0x00000000000002a0 0x00000000000002a0 R 0x8 INTERP 0x00000000000002e0 0x00000000000002e0 0x00000000000002e0 0x0000000000000015 0x0000000000000015 R 0x1 [Requesting program interpreter: /libexec/ld-elf.so.1] LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000863f70 0x0000000000863f70 R 0x1000 LOAD 0x0000000000863f70 0x0000000000864f70 0x0000000000864f70 0x00000000010597d0 0x00000000010597d0 R E 0x1000 LOAD 0x00000000018bd740 0x00000000018bf740 0x00000000018bf740 0x000000000013e0d0 0x000000000013e0d0 RW 0x1000 LOAD 0x00000000019fb810 0x00000000019fe810 0x00000000019fe810 0x0000000000020990 0x0000000000025df0 RW 0x1000 TLS 0x00000000018bd740 0x00000000018bf740 0x00000000018bf740 0x0000000000000021 0x00000000000002e0 R 0x8 DYNAMIC 0x00000000019f97a8 0x00000000019fb7a8 0x00000000019fb7a8 0x00000000000001e0 0x00000000000001e0 RW 0x8 GNU_RELRO 0x00000000018bd740 0x00000000018bf740 0x00000000018bf740 0x000000000013e0d0 0x000000000013e8c0 R 0x1 GNU_EH_FRAME 0x000000000068069c 0x000000000068069c 0x000000000068069c 0x000000000005e1bc 0x000000000005e1bc R 0x4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0 NOTE 0x00000000000002f8 0x00000000000002f8 0x00000000000002f8 0x0000000000000030 0x0000000000000030 R 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.tag .dynsym .gnu.version .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn .rela.plt .rodata .gcc_except_table .eh_frame_hdr .eh_frame 03 .text .init .fini .plt 04 .tdata .tbss .ctors .dtors .jcr .init_array .data.rel.ro .dynamic .got .got.plt 05 .data .sdata .sbss .bss 06 .tdata .tbss 07 .dynamic 08 .tdata .tbss .ctors .dtors .jcr .init_array .data.rel.ro .dynamic .got .got.plt 09 .eh_frame_hdr 10 11 .note.tag There are 46 section headers, starting at offset 0x2ef1470: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .interp PROGBITS 00000000000002e0 000002e0 0000000000000015 0000000000000000 A 0 0 1 [ 2] .note.tag NOTE 00000000000002f8 000002f8 0000000000000030 0000000000000000 A 0 0 4 [ 3] .dynsym DYNSYM 0000000000000328 00000328 0000000000001a88 0000000000000018 A 8 1 8 [ 4] .gnu.version SUNW_versym 0000000000001db0 00001db0 0000000000000236 0000000000000002 A 3 0 2 [ 5] .gnu.version_r SUNW_verneed 0000000000001fe8 00001fe8 0000000000000110 0000000000000000 A 8 4 4 [ 6] .gnu.hash GNU_HASH 00000000000020f8 000020f8 0000000000000028 0000000000000000 A 3 0 8 [ 7] .hash HASH 0000000000002120 00002120 00000000000008e0 0000000000000004 A 3 0 4 [ 8] .dynstr STRTAB 0000000000002a00 00002a00 0000000000000cec 0000000000000000 A 0 0 1 [ 9] .rela.dyn RELA 00000000000036f0 000036f0 00000000001b6510 0000000000000018 A 3 0 8 [10] .rela.plt RELA 00000000001b9c00 001b9c00 0000000000001950 0000000000000018 AI 3 28 8 [11] .rodata PROGBITS 00000000001bb580 001bb580 000000000030eca3 0000000000000000 AMS 0 0 64 [12] .gcc_except_table PROGBITS 00000000004ca224 004ca224 00000000001b6478 0000000000000000 A 0 0 4 [13] .eh_frame_hdr PROGBITS 000000000068069c 0068069c 000000000005e1bc 0000000000000000 A 0 0 4 [14] .eh_frame PROGBITS 00000000006de858 006de858 0000000000185718 0000000000000000 A 0 0 8 [15] .text PROGBITS 0000000000864f70 00863f70 00000000010586a6 0000000000000000 AX 0 0 16 [16] .init PROGBITS 00000000018bd616 018bc616 0000000000000012 0000000000000000 AX 0 0 1 [17] .fini PROGBITS 00000000018bd628 018bc628 0000000000000012 0000000000000000 AX 0 0 1 [18] .plt PROGBITS 00000000018bd640 018bc640 0000000000001100 0000000000000000 AX 0 0 16 [19] .tdata PROGBITS 00000000018bf740 018bd740 0000000000000021 0000000000000000 WAT 0 0 8 [20] .tbss NOBITS 00000000018bf768 018bd761 00000000000002b8 0000000000000000 WAT 0 0 8 [21] .ctors PROGBITS 00000000018bf768 018bd768 0000000000000010 0000000000000000 WA 0 0 8 [22] .dtors PROGBITS 00000000018bf778 018bd778 0000000000000010 0000000000000000 WA 0 0 8 [23] .jcr PROGBITS 00000000018bf788 018bd788 0000000000000008 0000000000000000 WA 0 0 8 [24] .init_array INIT_ARRAY 00000000018bf790 018bd790 0000000000000010 0000000000000000 WA 0 0 8 [25] .data.rel.ro PROGBITS 00000000018bf7a0 018bd7a0 000000000013c008 0000000000000000 WA 0 0 8 [26] .dynamic DYNAMIC 00000000019fb7a8 019f97a8 00000000000001e0 0000000000000010 WA 8 0 8 [27] .got PROGBITS 00000000019fb988 019f9988 0000000000001608 0000000000000000 WA 0 0 8 [28] .got.plt PROGBITS 00000000019fcf90 019faf90 0000000000000880 0000000000000000 WA 0 0 8 [29] .data PROGBITS 00000000019fe810 019fb810 000000000000df00 0000000000000000 WA 0 0 8 [30] .sdata PROGBITS 0000000001a0c710 01a09710 0000000000012a90 0000000000000000 WA 0 0 8 [31] .sbss NOBITS 0000000001a1f1a0 01a1c1a0 0000000000000121 0000000000000000 WA 0 0 8 [32] .bss NOBITS 0000000001a1f300 01a1c1a0 0000000000005300 0000000000000000 WA 0 0 64 [33] .debug_loc PROGBITS 0000000000000000 01a1c1a0 0000000000000440 0000000000000000 0 0 1 [34] .debug_abbrev PROGBITS 0000000000000000 01a1c5e0 0000000000000390 0000000000000000 0 0 1 [35] .debug_info PROGBITS 0000000000000000 01a1c970 000000000000083b 0000000000000000 0 0 1 [36] .debug_str PROGBITS 0000000000000000 01a1d1ab 00000000000002bd 0000000000000001 MS 0 0 1 [37] .comment PROGBITS 0000000000000000 01a1d468 00000000000000f6 0000000000000001 MS 0 0 1 [38] .riscv.attributes LOPROC+0x3 0000000000000000 01a1d55e 000000000000004a 0000000000000000 0 0 1 [39] .debug_frame PROGBITS 0000000000000000 01a1d5a8 0000000000000150 0000000000000000 0 0 8 [40] .debug_line PROGBITS 0000000000000000 01a1d6f8 00000000000006f7 0000000000000000 0 0 1 [41] .debug_aranges PROGBITS 0000000000000000 01a1ddef 00000000000000b0 0000000000000000 0 0 1 [42] .debug_ranges PROGBITS 0000000000000000 01a1de9f 00000000000000a0 0000000000000000 0 0 1 [43] .symtab SYMTAB 0000000000000000 01a1df40 0000000000bd6678 0000000000000018 45 506846 8 [44] .shstrtab STRTAB 0000000000000000 025f45b8 00000000000001af 0000000000000000 0 0 1 [45] .strtab STRTAB 0000000000000000 025f4767 00000000008fcd07 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Dynamic section at offset 0x19f97a8 contains 30 entries: Tag Type Name/Value 0x000000000000001d RUNPATH Library runpath: [$ORIGIN/../lib] 0x0000000000000001 NEEDED Shared library: [libthr.so.3] 0x0000000000000001 NEEDED Shared library: [libgcc_s.so.1] 0x0000000000000001 NEEDED Shared library: [libc.so.7] 0x0000000000000001 NEEDED Shared library: [libm.so.5] 0x000000000000001e FLAGS ORIGIN BIND_NOW 0x000000006ffffffb FLAGS_1 NOW ORIGIN PIE 0x0000000000000015 DEBUG 0x0 0x0000000000000007 RELA 0x36f0 0x0000000000000008 RELASZ 1795344 (bytes) 0x0000000000000009 RELAENT 24 (bytes) 0x000000006ffffff9 RELACOUNT 74731 0x0000000000000017 JMPREL 0x1b9c00 0x0000000000000002 PLTRELSZ 6480 (bytes) 0x0000000000000003 PLTGOT 0x19fcf90 0x0000000000000014 PLTREL RELA 0x0000000000000006 SYMTAB 0x328 0x000000000000000b SYMENT 24 (bytes) 0x0000000000000005 STRTAB 0x2a00 0x000000000000000a STRSZ 3308 (bytes) 0x000000006ffffef5 GNU_HASH 0x20f8 0x0000000000000004 HASH 0x2120 0x0000000000000019 INIT_ARRAY 0x000000000000001b INIT_ARRAYSZ 16 (bytes) 0x000000000000000c INIT 0x18bd616 0x000000000000000d FINI 0x18bd628 0x000000006ffffff0 VERSYM 0x1db0 0x000000006ffffffe VERNEED 0x1fe8 0x000000006fffffff VERNEEDNUM 4 0x0000000000000000 NULL 0x0 Version symbol section (.gnu.version): 000: 0 *local* 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 004: 2 FBSD_1.0 1 *global* 2 FBSD_1.0 3 GCC_3.0 008: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 00c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 010: 2 FBSD_1.0 2 FBSD_1.0 4 FBSD_1.2 5 FBSD_1.0 014: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 6 FBSD_1.0 018: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 01c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 020: 2 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 024: 6 FBSD_1.0 2 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 028: 6 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 02c: 6 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 030: 2 FBSD_1.0 2 FBSD_1.0 6 FBSD_1.0 7 FBSD_1.5 034: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 038: 2 FBSD_1.0 7 FBSD_1.5 2 FBSD_1.0 2 FBSD_1.0 03c: 2 FBSD_1.0 2 FBSD_1.0 8 FBSD_1.3 2 FBSD_1.0 040: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 7 FBSD_1.5 044: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 048: 2 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 04c: 6 FBSD_1.0 6 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 050: 9 FBSD_1.1 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 054: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 6 FBSD_1.0 058: 6 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 05c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 060: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 064: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 068: 7 FBSD_1.5 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 06c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 070: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 074: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 078: 6 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 6 FBSD_1.0 07c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 080: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 084: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 088: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 08c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 090: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 094: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 098: 5 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 8 FBSD_1.3 09c: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0a0: 6 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0a4: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0a8: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0ac: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0b0: 2 FBSD_1.0 a FBSD_1.2 2 FBSD_1.0 2 FBSD_1.0 0b4: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0b8: 2 FBSD_1.0 7 FBSD_1.5 6 FBSD_1.0 6 FBSD_1.0 0bc: 6 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0c0: 2 FBSD_1.0 2 FBSD_1.0 5 FBSD_1.0 b GCC_4.6.0 0c4: b GCC_4.6.0 b GCC_4.6.0 b GCC_4.6.0 b GCC_4.6.0 0c8: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0cc: b GCC_4.6.0 b GCC_4.6.0 6 FBSD_1.0 6 FBSD_1.0 0d0: 6 FBSD_1.0 6 FBSD_1.0 b GCC_4.6.0 b GCC_4.6.0 0d4: b GCC_4.6.0 b GCC_4.6.0 2 FBSD_1.0 2 FBSD_1.0 0d8: 2 FBSD_1.0 6 FBSD_1.0 2 FBSD_1.0 a FBSD_1.2 0dc: 9 FBSD_1.1 9 FBSD_1.1 2 FBSD_1.0 2 FBSD_1.0 0e0: c FBSD_1.4 c FBSD_1.4 8 FBSD_1.3 2 FBSD_1.0 0e4: 2 FBSD_1.0 9 FBSD_1.1 6 FBSD_1.0 6 FBSD_1.0 0e8: 6 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 6 FBSD_1.0 0ec: 9 FBSD_1.1 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 0f0: 2 FBSD_1.0 d FBSD_1.7 9 FBSD_1.1 9 FBSD_1.1 0f4: 9 FBSD_1.1 9 FBSD_1.1 9 FBSD_1.1 2 FBSD_1.0 0f8: 2 FBSD_1.0 9 FBSD_1.1 9 FBSD_1.1 9 FBSD_1.1 0fc: 9 FBSD_1.1 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 100: 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 2 FBSD_1.0 104: 3 GCC_3.0 3 GCC_3.0 3 GCC_3.0 e GCC_4.2.0 108: 3 GCC_3.0 3 GCC_3.0 3 GCC_3.0 2 FBSD_1.0 10c: 7 FBSD_1.5 2 FBSD_1.0 9 FBSD_1.1 2 FBSD_1.0 110: 2 FBSD_1.0 2 FBSD_1.0 8 FBSD_1.3 6 FBSD_1.0 114: 6 FBSD_1.0 6 FBSD_1.0 3 GCC_3.0 3 GCC_3.0 118: 1 *global* 1 *global* 1 *global* Version needed section (.gnu.version_r): 0x0000 vn_version: 1 vn_file: libthr.so.3 vn_cnt: 1 0x0040 vna_name: FBSD_1.0 vna_flags: 0 vna_other: 6 0x0010 vn_version: 1 vn_file: libgcc_s.so.1 vn_cnt: 3 0x0050 vna_name: GCC_3.0 vna_flags: 0 vna_other: 3 0x0060 vna_name: GCC_4.2.0 vna_flags: 0 vna_other: 14 0x0070 vna_name: GCC_4.6.0 vna_flags: 0 vna_other: 11 0x0020 vn_version: 1 vn_file: libc.so.7 vn_cnt: 7 0x0080 vna_name: FBSD_1.0 vna_flags: 0 vna_other: 2 0x0090 vna_name: FBSD_1.1 vna_flags: 0 vna_other: 9 0x00a0 vna_name: FBSD_1.2 vna_flags: 0 vna_other: 10 0x00b0 vna_name: FBSD_1.3 vna_flags: 0 vna_other: 8 0x00c0 vna_name: FBSD_1.4 vna_flags: 0 vna_other: 12 0x00d0 vna_name: FBSD_1.5 vna_flags: 0 vna_other: 7 0x00e0 vna_name: FBSD_1.7 vna_flags: 0 vna_other: 13 0x0030 vn_version: 1 vn_file: libm.so.5 vn_cnt: 2 0x00f0 vna_name: FBSD_1.0 vna_flags: 0 vna_other: 5 0x0100 vna_name: FBSD_1.2 vna_flags: 0 vna_other: 4 console# Lovely, looks like rust has a hard dependency on libgcc_s.so.1 Day three with the COMPAT11 in place on FreeBSD 15.0-CURRENT. After four days of thrashing the build of lang/rust the SiFive RISC-V board known as HiFive Unmatched Rev B ran out of swap and then the build process died. Seen on the console : swap_pager: out of swap space swp_pager_getswapspace(28): failed swap_pager: out of swap space swp_pager_getswapspace(19): failed Oct 1 11:45:34 enceladus kernel: pid 93520 (bsdtar), jid 3, uid 0, was killed: failed to reclaim memory swp_pager_getswapspace(11): failed Oct 1 11:45:37 enceladus kernel: pid 1771 (ntpd), jid 0, uid 0, was killed: failed to reclaim memory swp_pager_getswapspace(1): failed Oct 1 11:45:40 enceladus kernel: pid 1963 (top), jid 0, uid 1001, was killed: failed to reclaim memory Oct 1 11:45:43 enceladus kernel: pid 1957 (sshd), jid 0, uid 1001, was killed: failed to reclaim memory swp_pager_getswapspace(22): failed swap_pager: out of swap space swp_pager_getswapspace(9): failed swap_pager: out of swap space swp_pager_getswapspace(3): failed Oct 1 11:45:46 enceladus kernel: pid 1845 (sshd), jid 0, uid 1001, was killed: failed to reclaim memory Oct 1 11:45:49 enceladus kernel: pid 1505 (devd), jid 0, uid 0, was killed: failed to reclaim memory swp_pager_getswapspace(21): failed Oct 1 11:45:51 enceladus kernel: pid 94189 (xargs), jid 0, uid 0, was killed: failed to reclaim memory That happened because my poudriere.conf had USE_TMPFS=yes and so now I have it set to a nice safe "no". From time to time I would check on the status of poudriere which was building a conservative little pile of packages. That final status I saw was late last night : . . . here I hit CTRL t load: 1.56 cmd: sh 41871 [running] 0.09r 0.00u 0.01s 3% 1428k [150rv64-latest] [2024-09-27_03h40m22s] [parallel_build] Queued: 72 Built: 56 Failed: 2 Skipped: 10 Ignored: 0 Fetched: 0 Tobuild: 4 Time: 4D:03:31:32 ID TOTAL ORIGIN PKGNAME PHASE PHASE TMPFS CPU% MEM% [02] 3D:23:48:48 lang/rust | rust-1.81.0 build 3D:23:39:43 20.67 GiB 81.4% 3.7% [4D:03:31:55] Logs: /poudriere/data/logs/bulk/150rv64-latest/2024-09-27_03h40m22s I would have thought that 16G of memory and 16G of swap was plenty but not when building rust. enceladus# uname -apKU FreeBSD enceladus 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n272477-5b8f97d8db82-dirty: Thu Sep 26 22:57:07 GMT 2024 root@enceladus:/usr/obj/usr/src/riscv.riscv64/sys/SIFIVE-COMPAT11 riscv riscv64 1500023 1500023 enceladus# swapinfo -k Device 1K-blocks Used Avail Capacity /dev/mirror/swap 16777212 4532 16772680 0% enceladus# I will start the poudriere bulk build again thus : enceladus# cat essential.list databases/sqlite3 devel/ccache devel/gdb devel/git dns/bind-tools editors/emacs editors/vim lang/gcc13 lang/go122 lang/python311 ports-mgmt/pkg ports-mgmt/poudriere security/gnupg shells/ksh93 sysutils/fastfetch sysutils/tmux textproc/groff x11-fonts/xlsfonts x11/xauth x11/xcb-util x11/xcb-util-wm x11/xlogo x11/xterm enceladus# enceladus# idprio 0 poudriere bulk -r -j 150rv64 -p latest -f essential.list [00:00:01] Creating the reference jail... done [00:00:01] Mounting system devices for 150rv64-latest [00:00:02] Warning: Using packages from previously failed, or uncommitted, build: /poudriere/data/packages/150rv64-latest/.building [00:00:02] Mounting ccache from: /var/cache/ccache [00:00:02] Mounting ports from: /poudriere/ports/latest [00:00:02] Mounting packages from: /poudriere/data/packages/150rv64-latest [00:00:02] Mounting distfiles from: /poudriere/distfiles /etc/resolv.conf -> /poudriere/data/.m/150rv64-latest/ref/etc/resolv.conf [00:00:02] Starting jail 150rv64-latest Updating /var/run/os-release done. [00:00:03] Will build as nobody:nobody (65534:65534) [00:00:22] Logs: /poudriere/data/logs/bulk/150rv64-latest/2024-10-01_19h19m36s [00:00:22] Loading MOVED for /poudriere/data/.m/150rv64-latest/ref/usr/ports [00:00:27] Ports supports: FLAVORS SUBPACKAGES SELECTED_OPTIONS [00:00:27] Inspecting ports tree for modifications to git checkout... no [00:01:08] Ports top-level git hash: 1779e67e6 [00:01:08] Gathering ports metadata [00:03:00] Calculating ports order and dependencies [00:03:13] Trimming IGNORED and blacklisted ports [00:03:17] Sanity checking the repository [00:03:17] Checking packages for incremental rebuild needs [00:04:05] Deleting stale symlinks... done [00:04:05] Deleting empty directories... done [00:04:09] Unqueueing existing packages [00:04:16] Unqueueing orphaned build dependencies [00:04:17] Sanity checking build queue [00:04:17] Processing PRIORITY_BOOST [00:04:18] Balancing pool [150rv64-latest] [2024-10-01_19h19m36s] [balancing_pool] Queued: 16 Built: 0 Failed: 0 Skipped: 0 Ignored: 0 Fetched: 0 Tobuild: 16 Time: 00:03:56 [00:04:18] Recording filesystem state for prepkg... done [00:04:22] Building 16 packages using up to 2 builders [00:04:22] Hit CTRL+t at any time to see build progress and stats [00:04:22] [01] [00:00:00] Builder starting [00:04:22] [02] [00:00:00] Builder starting [00:04:24] [01] [00:00:02] Builder started [00:04:24] [01] [00:00:00] Building devel/highway | highway-1.2.0 [00:04:25] [02] [00:00:03] Builder started [00:04:25] [02] [00:00:00] Building print/texlive-texmf | texlive-texmf-20240312_1 . . . So now we wait another five days. Or more. well it didn't take too long to get the lang/rust build to restart : [00:07:58] [01] [00:03:34] Skipping graphics/ImageMagick7@x11 | ImageMagick7-7.1.1.26_5: Dependent port devel/highway | highway-1.2.0 failed [00:07:58] [01] [00:03:34] Skipping graphics/chafa | chafa-1.14.4_1: Dependent port devel/highway | highway-1.2.0 failed [00:07:58] [01] [00:03:34] Skipping sysutils/fastfetch | fastfetch-2.25.0: Dependent port devel/highway | highway-1.2.0 failed [00:07:58] [01] [00:03:34] Skipping multimedia/ffmpeg | ffmpeg-6.1.2_2,1: Dependent port devel/highway | highway-1.2.0 failed [00:07:58] [01] [00:03:34] Skipping graphics/libheif | libheif-1.18.2: Dependent port devel/highway | highway-1.2.0 failed [00:07:58] [01] [00:03:34] Skipping graphics/libjxl | libjxl-0.11.0: Dependent port devel/highway | highway-1.2.0 failed [00:07:58] [01] [00:00:00] Building lang/rust | rust-1.81.0 However now the storage activity led is flashing madly due to USE_TMPFS=no.
With USE_TMPFS=no I finally see :
=======================<phase: package >============================
===== env: 'PKG_NOTES=build_timestamp ports_top_git_hash ports_top_checkout_unclean port_git_hash port_checkout_unclean built_by' 'PKG_NOTE_build_timestamp=2024-10-01T19:27:40+0000' 'PKG_NOTE_ports_top_git_hash=1779e67e6' 'PKG_NOTE_ports_top_checkout_unclean=no' 'PKG_NOTE_port_git_hash=26df8c65a' 'PKG_NOTE_port_checkout_unclean=no' 'PKG_NOTE_built_by=poudriere-git-3.4.2' NO_DEPENDS=yes USER=root UID=0 GID=0
===> Building packages for rust-1.81.0
===> Building rust-1.81.0
===========================================================================
=>> Cleaning up wrkdir
===> Cleaning for rust-1.81.0
build of lang/rust | rust-1.81.0 ended at Thu Oct 3 20:58:32 UTC 2024
build time: 2D:01:30:58
Which is bizarre given that the machine thrashed for over four days when
using tmpfs.
Regardless the COMPAT11 hack allows lang/rust to build :
enceladus# pkg install lang/rust
Updating RV64 repository catalogue...
Fetching meta.conf: 100% 178 B 0.2kB/s 00:01
Fetching data.pkg: 100% 98 KiB 100.6kB/s 00:01
Processing entries: 100%
RV64 repository update completed. 372 packages processed.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
rust: 1.81.0
Number of packages to be installed: 1
The process will require 1 GiB more space.
Proceed with this action? [y/N]: y
[1/1] Installing rust-1.81.0...
[1/1] Extracting rust-1.81.0: 100%
enceladus#
enceladus# uname -apKU
FreeBSD enceladus 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n272477-5b8f97d8db82-dirty: Thu Sep 26 22:57:07 GMT 2024 root@enceladus:/usr/obj/usr/src/riscv.riscv64/sys/SIFIVE-COMPAT11 riscv riscv64 1500023 1500023
enceladus#
enceladus# rustc --version
rustc 1.81.0 (f54dd915b 2024-09-02) (built from a source tarball)
enceladus#
This is hardly a happy result due to the problems well documented all over
the place on github regarding Rust. However, yes, the lang/rust port completes.
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
I really want to confirm or replicate your result. Can you confirm the changes required to make this happen? In my effort to replicate this result, I put COMPAT11 in the kernel and retried rust. It worked. OKay .. it seems to build and install but I need time to verify that it works with a testsuite : enceladus# uname -apKU FreeBSD enceladus 15.0-CURRENT FreeBSD 15.0-CURRENT #0 main-n272477-5b8f97d8db82-dirty: Thu Sep 26 22:57:07 GMT 2024 root@enceladus:/usr/obj/usr/src/riscv.riscv64/sys/SIFIVE-COMPAT11 riscv riscv64 1500023 1500023 enceladus# rustc --version rustc 1.81.0 (f54dd915b 2024-09-02) (built from a source tarball) enceladus# I think we should add COMPAT_FREEBSD11 and COMPAT_FREEBSD12 to RISC-V even though risc-v wasn't available on those FreeBSD releases. We did this for powerpc64le - it appeared on FreeBSD 13. I can confirm that some applications like lang/rust and lang/go depends on those old interfaces until someone updates them. riscv's GENERIC already has COMPAT_FREEBSD12, because riscv was supported in 12.0. We're not going to add compat code for system calls that never existed because rust has dysfunctional FreeBSD support that is still targeting a lowest not-even-common denominator that's been EOL for almost a year. It's rust's problem to conform to how FreeBSD works if it wants to claim to actually support FreeBSD, not FreeBSD's problem to bend to the will of userspace developers who think FreeBSD should look a certain way. (In reply to Jessica Clarke from comment #20) I used to agree but I changed my mind while trying to make powerpc* userland usable. I realized that it would be a waste of time fixing an undetermined number of packages, maintaining the patches and so while waiting them to get accepted by upstream. In my experience, upstream wouldn't care much about updating because they don't see any benefit on changing something that's working for a long time just because of new Tier 2 platform. I see riscv would be more appealing than powerpc* at this point but someone at FreeBSD side should work with affected projects to get interfaces updated. In any case, I assume old interfaces are supported: amd64 keeps COMPAT_FREEBSD[4-14] (except 8, for some reason) While I want to think that FreeBSD is at the core of people's life, that's the arrogant thing about rust that makes the rust community so toxic to deal with. If we were not maintaining those interfaces in amd64 _or_ if it didn't make rust work, then I might tilt towards holding out. AFAICT, there's no additional work to having COMPAT* work. No libraries, no code --- isn't all of COMPAT* simply sub functions that forward to new stuff? I would call US out for being silly to not recommend this change. It's a zero effort change and it fixes a very real problem. (In reply to Jessica Clarke from comment #20) You can have ideological purity or working software, pick one. I don't get why you are so hung up on that. The only one who suffers are RISC-V users. Same with all the issues that prevent the RISC-V build from being self hosting, for which trivial patches exist that have nevertheless not been committed because they aren't elegant and a better solution should be found. Why not just put the fixes in and replace them with elegant fixes once those have been developed? I really don't get it. This waiting for the ideal solution brought by the knight in a shiny armor on a white horse reminds me of https://lists.freebsd.org/pipermail/freebsd-hackers/2007-September/021722.html 17 years ago briefly we had working sensors framework, we still don't because some devs found the framework not good enough. I wonder whether we'll wait for the Rust on riscv* also at least 17 years. Meanwhile, Rust on powerpc64le still seems to work fine Hi all, I have been following this bug, and the larger issue of Rust on FreeBSD/riscv64, for a long time now. The desires for better defaults here are heard. I am in contact with Alan Somers (asomers@) who is in-the-know on the transition away from FreeBSD 11 syscalls within the rust project. Essentially, we are closer than ever, but the rust developers are hesitant to make the switch officially, due to concerns/lack of confidence about backwards compatibility, and a couple of smaller TODOs. Thus, there is still no firm timeline for the transition. He suggested that in the meantime, we would be able to switch to the FreeBSD 12 ABI by default for the riscv64 target specifically. I am working with him to test this, and if this solution proves workable in the near-term, our problem will be solved. If this course of action doesn't work out by the end of this year, I will enable COMPAT11 in GENERIC as a stop-gap. At the point that Rust has officially moved off of the FreeBSD 11 interfaces, the compatibility will be removed and users will be required to upgrade their ports. The discussion has repeated in circles for years now, and it is tiring to see. We need to take some kind of step forward. What we are talking about is a triply-niche platform: an alternative programming language, on an alternative operating system, on an emerging CPU architecture. In other words, we are very much the small fish in this scenario. Robert is absolutely correct that by taking such a hard-line stance towards Rust's technical inadequacies, legitimate as they may be, _we_ are the ones who are losing in practical terms. In the same vein, those of you who are interested and willing to experiment with such an unofficial and immature platform as Rust on FreeBSD/riscv are expected to carry your weight in terms of workarounds, dealing with stumbling blocks, unclear instructions, etc. This means in the immediate-term you will have to be comfortable with maintaining a custom kernel config adding COMPAT11, if you want to experiment with Rust. For the three or four people that make up this group, this is not an unreasonable ask at all. To reiterate: I intend to take action to get us "unstuck" here, in the near-term, but not immediately. It is important that we continue to improve the out-of-the-box experience, but our pool of users is tiny and the pool of developers is minuscule. As a final request: please, do not post any more console output to this bug, unless it is requested specifically. You can share successes/challenges relating to building/running Rust ports on the freebsd-riscv mailing list. Thanks. Mitchell (In reply to Mitchell Horne from comment #25) I have commented on this bug not because I am personally interested in Rust, but rather because Rust-based libraries are dependencies to many common ports. With Rust broken, a lot of stuff doesn't build or only builds with non-default options (i.e. is not available using pkg-install(8) unless one manually builds a repository with different options). This means that for me it is very hard to test other ports and packages on riscv64. Sure I can build a kernel with non-default options, but then the patches I write will not be useful to users. I have really tried to have fun working on ports and other projects for riscv64, but there are so many annoyances and roadblocks (chiefly among these: a few stupid build system bugs that make the build not self-hosting, and this purely ideological issue) that I basically gave up. It doesn't help that we only support less than a handful of boards and they are all dog slow. This summer I then went ahead and mentored a student who was supposed to write SIMD accelerated libc string functions for Rust. For this purpose, it would have been useful to optionally make use of an ISA extension (specifically, the Zbb extension) supported by many of the boards out there. Turns out this was impossible: there is no way for user software to detect the availability of this feature and we didn't have support for ifunc-based dispatching. While a patch for the latter was eventually (but way too late to be useful) supplied, there seems to be an inability to make any pragmatic decision on ISA extension detection that would have allowed us to carry out this project. Apparently we are waiting for some RISC-V committee to make a design decision on the perfect™ interface that seems years away. We ended up not pursuing this further after wasting a few weeks and significantly reduced the scope of the GSoC project. The joint factor in all three problems is an absolute refusal of the people working on the riscv64 port to make any sort of pragmatic decisions. Nothing is done anywhere until the perfect final ethernal solution has been obtained. It doesn't matter if user software doesn't run, the system cannot be upgraded, or other developers get blocked with their projects indefinitely. No, ideological purity most be preserved at any cost! Maybe reconsider this approach. Being more pragmatic would seriously help us make riscv64 FreeBSD a more attractive platform to hack on. FreeBSD is a volunteer-led project, and that's particularly true of riscv64. Nobody owes you any patches, and nobody stopped you providing one for IFUNCs. It is quite frankly rude to complain about the fact that I took the time to write it for you just because I didn't do so as early as you wanted. Not to mention that this is entirely off-topic for this bug report. (In reply to Mitchell Horne from comment #25) Could we add your patch on lang/rust package? I have no idea how many other packages depend on COMPAT11 nowadays, but that would be a balanced solution to make lang/rust users happy now. And also make upstream more comfortable with the change, by having it being validated in the field. So the patch, to make this compile and work, is to put COMPAT_FREEBSD11 into the kernel and recompile the kernel. Then things work. Now obviously, several people here understand, but just to be clear: Languages like rust don't use libc (or use it sparingly). In their own equivalent of libc, they call syscalls _directly_. Now, there do not exist ports that sensibly depend on COMPAT_11 on risc-v for FreeBSD because 11 was deprecated before FreeBSD ran on risc-v. But, a language that doesn't use libc and calls syscalls directly can be written to use the FreeBSD-11 set of syscalls. Technically the nirvana of shared libraries is the idea that a binary can function without even knowing about syscalls --- as they're all provided for the binary --- and provided in updated form such that the binary still runs. COMPAT and friends are needed, in those cases, when a statically linked binary is in play --- as it might call old syscalls that no longer exist. This is not the play here. Think of rust as an entirely different and somewhat incompatible way to generate those binaries, that, from the perview of the OS, are in the same bin as statically linked. We provide the userland shared libraries --- this "upgrades" most things, but not, sadly, rust. (In reply to dgilbert from comment #29) > So the patch, to make this compile and work, is to put COMPAT_FREEBSD11 > into the kernel and recompile the kernel. Then things work. I wasn't very clear, sorry. My suggestion was commit mhorne's patches that adds FREEBSD12 syscall support to Rust on FreeBSD's "lang/rust" port as an alternative. (In reply to Alfredo Dal'Ava Junior from comment #30) The COMPAT_11 problem cannot be fixed by patching the compiler alone. The problem stems from the bindings used by the libc crate. That crate is used either directly or indirectly by almost every single Rust crate. And when building a port, our ports tree fetches every crate used by that port. So to patch our way around this problem, we would have to end up patching almost every single Rust-depending port in the tree. |
Created attachment 253676 [details] poudriere log for rust build on 15-current risc-v Rust failing to build again on risc-v. Half our port tree seems to depend on it now (emacs, for instance). Error seems to happen here: [00:06:51] ===> Configuring for rust-1.81.0 [00:06:59] ===> FreeBSD 10 autotools fix applied to /wrkdirs/usr/ports/lang/rust/work/rustc-1.81.0-src/vendor/libssh2-sys-0.3.0/libssh2/config.rpath [00:06:59] ===> FreeBSD 10 autotools fix applied to /wrkdirs/usr/ports/lang/rust/work/rustc-1.81.0-src/vendor/libssh2-sys-0.2.23/libssh2/config.rpath [00:07:03] Bad system call [00:07:03] => Sanity check failed: kernel is missing COMPAT_FREEBSD11 [00:07:03] => Aborting build [00:07:03] *** Error code 1 ... but the full build log from poudriere is attached.