Bug 281600 - lang/rust failing to build on risc-v (again)
Summary: lang/rust failing to build on risc-v (again)
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: riscv Any
: --- Affects Many People
Assignee: Mitchell Horne
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-20 05:18 UTC by dgilbert
Modified: 2024-11-05 20:09 UTC (History)
10 users (show)

See Also:
bugzilla: maintainer-feedback? (rust)


Attachments
poudriere log for rust build on 15-current risc-v (19.10 KB, text/plain)
2024-09-20 05:18 UTC, dgilbert
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description dgilbert 2024-09-20 05:18:46 UTC
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.
Comment 1 Dennis Clarke 2024-09-20 16:27:49 UTC
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.
Comment 2 dgilbert 2024-09-20 18:23:46 UTC
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.
Comment 3 Robert Clausecker freebsd_committer freebsd_triage 2024-09-24 11:17:44 UTC
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.
Comment 4 Dennis Clarke 2024-09-24 11:47:41 UTC
(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.
Comment 5 Mikael Urankar freebsd_committer freebsd_triage 2024-09-24 12:20:33 UTC
(In reply to Dennis Clarke from comment #4)
Just add compat11 to your kernel config and build / install this kernel.
Comment 6 Robert Clausecker freebsd_committer freebsd_triage 2024-09-24 13:12:33 UTC
(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.
Comment 7 Tomasz "CeDeROM" CEDRO 2024-09-24 21:07:17 UTC
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?
Comment 8 Dennis Clarke 2024-09-25 00:05:38 UTC
(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
Comment 9 Dennis Clarke 2024-09-26 21:22:57 UTC
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.
Comment 10 Dennis Clarke 2024-09-28 17:43:38 UTC
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.
Comment 11 dgilbert 2024-09-28 22:30:03 UTC
Are there patches, or is it all in the tree?
Comment 12 Dennis Clarke 2024-09-30 11:56:48 UTC
(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.
Comment 13 Dennis Clarke 2024-10-01 19:24:46 UTC
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.
Comment 14 Dennis Clarke 2024-10-01 19:32:51 UTC
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.
Comment 15 Dennis Clarke 2024-10-05 18:29:19 UTC
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
Comment 16 dgilbert 2024-10-05 20:33:34 UTC
I really want to confirm or replicate your result.  Can you confirm the changes required to make this happen?
Comment 17 dgilbert 2024-10-10 05:01:18 UTC
In my effort to replicate this result, I put COMPAT11 in the kernel and retried rust.  It worked.
Comment 18 Dennis Clarke 2024-10-11 07:41:37 UTC
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#
Comment 19 Alfredo Dal'Ava Junior freebsd_committer freebsd_triage 2024-10-16 01:01:16 UTC
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.
Comment 20 Jessica Clarke freebsd_committer freebsd_triage 2024-10-16 01:09:04 UTC
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.
Comment 21 Alfredo Dal'Ava Junior freebsd_committer freebsd_triage 2024-10-16 01:49:35 UTC
(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)
Comment 22 dgilbert 2024-10-16 03:56:38 UTC
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.
Comment 23 Robert Clausecker freebsd_committer freebsd_triage 2024-10-16 06:37:19 UTC
(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.
Comment 24 Piotr Kubaj freebsd_committer freebsd_triage 2024-10-16 11:39:25 UTC
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
Comment 25 Mitchell Horne freebsd_committer freebsd_triage 2024-10-16 17:59:00 UTC
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
Comment 26 Robert Clausecker freebsd_committer freebsd_triage 2024-10-18 14:19:15 UTC
(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.
Comment 27 Jessica Clarke freebsd_committer freebsd_triage 2024-10-18 14:40:33 UTC
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.
Comment 28 Alfredo Dal'Ava Junior freebsd_committer freebsd_triage 2024-10-18 23:25:53 UTC
(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.
Comment 29 dgilbert 2024-10-19 04:40:35 UTC
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.
Comment 30 Alfredo Dal'Ava Junior freebsd_committer freebsd_triage 2024-11-05 16:30:06 UTC
(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.