一直出现
在使用 devtools（extra-riscv64-build、mkarchroot 等）进行打包时，即使你在宿主机里是 root，在 chroot 环境里的用户和权限也未必与宿主机同步。因此，就会出现你在宿主系统执行 whoami 显示为 root，但在 chroot 内部却提示 “gyx1 is not in the sudoers file” 的问题。

换句话说：

宿主机和chroot是两个不同的系统环境；
在宿主机里你是 root 并不代表进了 chroot 后也能以同样的身份运行命令；
devtools 默认会在 chroot 内创建/使用一个普通用户（往往与 PKGBUILD 里的 pkgbuild_user 配置有关），而不是让你直接在 chroot 里当 root 操作。
这对工具本身来说应该是个大bug

sudo pacman -Syu devtools
我更新了devtools没有用,在想是不是环境污染了的问题
extra-riscv64-build -- -c
解决了

clang版本有问题,进入配好的riscv环境看看配置.
不过怎么进虚拟机呀.

sudo systemd-nspawn -D ./archriscv/ --machine archriscv -a -U

你的问题是在新分支 ruby-pycall 中，git log 仍然显示 commit 143157fa6c9a9f954ff787102b8ea184b1d3ba01 属于 origin/rbenv 分支的历史，即你的提交历史仍然和 origin/rbenv 共享。

🚀 为什么会这样？
当你创建 ruby-pycall 分支时：

bash
复制
编辑
git checkout -b ruby-pycall origin/ruby-pycall
或

bash
复制
编辑
git switch -c ruby-pycall origin/ruby-pycall
如果 ruby-pycall 和 rbenv 以前是相同的提交历史，你的新分支 ruby-pycall 只是一个指向同一个 commit 的分支，还没有新的提交。

🔍 如何确认 ruby-pycall 分支的提交历史
运行以下命令查看分支关系：

bash
复制
编辑
git branch -av
如果 ruby-pycall 仍然指向 origin/rbenv，会看到类似：

yaml
复制
编辑

ruby-pycall 143157f addpatch: rbenv 1.3.2-1
origin/rbenv 143157f addpatch: rbenv 1.3.2-1
这说明 ruby-pycall 只是一个分支名，它的 HEAD 仍然指向同一个 commit。

🔧 解决方案
✅ 方法 1：创建新提交
如果你希望 ruby-pycall 分支不再和 rbenv 共享历史，只需要在 ruby-pycall 分支上进行新的提交：

bash
复制
编辑
echo “New changes” > newfile.txt
git add newfile.txt
git commit -m “New commit in ruby-pycall”
然后 git log 会显示 ruby-pycall 分支有新的 commit。

✅ 方法 2：强制重置 ruby-pycall 到新的状态
如果你希望 ruby-pycall 和 rbenv 彻底分开，你可以重置 ruby-pycall：

bash
复制
编辑
git checkout ruby-pycall
git reset –hard HEAD~1 # 让 ruby-pycall 回退 1 个 commit（谨慎使用）
或者完全清空并重新创建：

bash
复制
编辑
git branch -D ruby-pycall
git checkout -b ruby-pycall
然后重新提交你的代码。

cffi

configue ->makefile->test ->lisp回调函数功能有一个在riscv64上没法实现
“please implement” error: This error message appears in ALIEN-CALLBACK-ASSEMBLER-WRAPPER and means that the SBCL developers have not yet written the assembly wrapper code required to generate callbacks for the current target platform (RISC-V 64-bit).

可能的错误原因:
回调函数的类型不匹配: 回调函数的参数或返回值类型可能与 C 代码的预期不一致。
平台或编译器问题: 当前环境是 RISC-V 架构，可能对 CFFI 的回调功能支持有限。
CFFI 配置问题: CFFI 的回调功能需要特定的配置，可能在当前环境中未正确设置。
SBCL 的限制: 使用的 Lisp 实现（SBCL）可能在当前版本中对回调功能支持不完整。

SB-ALIEN-INTERNALS:ALIEN-CALLBACK-ASSEMBLER-WRAPPER 和 SB-ALIEN::%ALIEN-CALLBACK-ALIEN 是 SBCL 内部用于支持 C 回调到 Lisp 的机制。
**它们帮助实现了从 C 语言到 Lisp 的回调桥接，并处理了调用约定、堆栈管理和数据传递等低级细节。些符号通常不是直接暴露给开发者使用的，而是在 SBCL 内部用于实现 FFI 相关功能
不同的硬件架构（如 x86 和 RISC-V）有不同的调用约定（calling conventions），即函数参数如何传递、返回值如何处理、函数调用时栈如何操作等。这些低级的细节通常由编译器和操作系统决定。

处理回调时，通常会涉及到汇编级别的细节，例如栈管理、函数参数传递、返回值传递等，这些在 RISC-V 和 x86 上的实现方式有差异。x86 架构的处理器通常支持较为直接的参数传递方式（如寄存器传递），而 RISC-V 的指令集和调用约定可能会有所不同。

对于 C 和 Lisp 之间的回调，这些细节变得尤为重要，尤其是在 RISC-V 上，CFFI 可能需要专门的低级实现（比如使用特殊的汇编代码）来确保回调正确工作。

SBCL 是一个跨平台的 Lisp 实现，支持多种架构，包括 x86、ARM 和 RISC-V 等，但它的支持在不同架构上的程度不完全相同。尽管 SBCL 为大多数架构提供了很好的支持，但在某些架构（特别是新兴的架构，如 RISC-V）上，可能存在一些特定功能的支持问题。

例如，SBCL 可能没有完全为 RISC-V 架构实现一些针对回调的细节支持，尤其是与 C 语言回调相关的机制。对于 x86，由于该架构更为广泛使用并且得到了更多优化，SBCL 和 CFFI 的回调机制工作得更加顺利。**

neovide

python-pyjsparser

把js代码转化为抽象语法树，用来静态分析js代码。
在容器里简单测试后，相信功能没有问题，但是缺少对 riscv64 的 js2py 依赖，使得官方测试是不可能的。所以我暂时跳过测试，等待 js2py 移植。

asciidoctor-pdf

因为arch社区采用回滚更新，所以一般只有最新版本。依赖版本出错是最经常碰到的问题。默认原则版本一般不超过主线，但是有一些要用旧版本才能测试成功的就不知道怎么办了。

libsieve

除了用的编译器不同以外没有任何区别，没有任何报错，但是就是riscv64下解析文件失败，X86正常
汇编层面的问题，虽然报错报的是语法错误，对照了一遍语法规定文件，找不出问题，发现但是最简单的测试都通不过，所以已经不是单纯的riscv64格式问题。是更底层的实现上的问题，
问题几乎肯定出在 ./example 这个测试工具或者它所使用的 libsieve 库在您当前的 riscv64 环境中的编译、安装或配置上。
可能的原因包括：
编译问题：libsieve 库或 ./example 工具在编译到 riscv64 平台时可能出错。例如，使用了不兼容的编译选项、遇到了 riscv64 特定的编译器 bug、或者代码中存在未考虑该架构的兼容性问题。
链接错误：程序可能链接了错误版本的依赖库。
运行时错误：可能存在内存对齐、指针处理等与 riscv64 架构相关的底层运行时问题，导致解析器内部状态损坏。

但是找到源代码，一层层找对应函数，最终发现是解析语法的汇编代码出错导致返回值为NULL。可能是还不支持riscv64
也编译可能出的问题，

这种“立即失败”并可能导致栈清空的 YYABORT，在迁移到 riscv64（尤其是在 WSL2 这种可能涉及模拟的环境下）时，可能由以下原因触发：

词法分析器 (yylex) 问题：yylex 函数（由 Flex/Lex 生成）在 riscv64 环境下可能一开始就行为异常。比如：
由于字符编码处理、I/O 问题或初始化错误，它可能立即返回了 YYerror 或一个非法的 token 值。
如果 yylex 立即返回 YYerror，解析器会进入 yyerrlab1。如果初始状态无法处理 error（这很常见），它会弹出初始状态，发现栈空 (yyssp == yyss)，然后 YYABORT。
早期内存损坏：由 riscv64 编译器（可能与 LTO 有关）生成的代码可能存在问题，或者运行时存在内存对齐、指针运算等错误，导致在解析开始时就破坏了 Bison 的内部状态栈 (yyss, yyvs) 或指针 (yyssp, yyvsp)，从而进入错误状态并可能触发 YYABORT。
初始化问题：解析器或词法分析器相关的初始化代码在 riscv64 环境下可能失败。

4.29重新追凶，从报错的地方挖进去。没法调试有点烦。我下个月要花时间搞一下gdb.
if没有大括号导致的错真是逆了天了.
从前往后找scripts完全没问题，也储存到buf了，所以开始从后往前找c->cur_call.values

修包常用思路

看源代码分析，层层深入。从报错往回找。初步接触一个肯定会看不懂，所以搞懂一个编译范式以后就可以通用。比如cargo，比如c的链接（configue->makefile）
x86_64和riscv64的编译文件比较
版本问题，因为更新导致的完整性校验问题。
因为arch社区采用回滚更新，所以一般只有最新版本。依赖版本出错是最经常碰到的问题。
测试问题（语法问题，输出结构不同问题（在不同的操作系统下同一个函数调用过程可能略有不一样，额外输出），底层定义不同问题unsigned-char，时间消耗问题）
依赖缺失问题
有些库在riscv64不支持，比如io就要选择性运行,还有一些运行需要的东西还没移植过来，比如js2py
有些测试文件本来就写的不太合理，x86环境下也运行不了，就向上游提pr
上游对riscv64在汇编层面的功能支持不够，导致有的因为缺接口编译过不了，有的编译通过但是因为不适用完全没法调用接口。
LLVM 19 为 riscv64 生成 IR → 机器码时触发了崩溃
包中包含的config.guess/config.sub太旧，当时还没有 riscv64 这一架构，无法把uname映射成标准的三段式三元组 riscv64-unknown-linux-gnu。有些在prepare阶段使用了autoreconf会起作用。也可以直接在./configure –build=riscv64-unknown-linux-gnu –host=riscv64-unknown-linux-gnu手动指定

指令集、寄存器名称和数量都完全不同。扩展指令少。
数据类型大小和对齐 (Data Type Sizes and Alignment)
条件编译: 使用预处理器指令（如 #ifdef riscv #ifdef__x86_64

config.guess: unable to guess system types上游文件过老。autoreconf -fi汇报到上游等待上游更新

cargo

在修包之前cargo和rust对我来说是完全陌生的东西。但是涉及到cargo的包太多，所以干脆花一下午去把一整个编译的结构摸了一遍，然后出问题定位就更容易，是用逻辑和测试能推出来的而不是一直全局搜索了。
unsafe代码块里直接涉及到内存和指针。
本身或依赖项，编译连接其他上游仓库写的库，他们riscv版本的写的不够完善，导致一个函数接口调用不到。只能去向上游报错，因为和riscv64的具体实现一整个缺失我也补不全。
buildrs太老了，无法从系统环境识别出工具链。
x86情况下用一种工具链，riscv64情况下使用cmake工具链，移植的时候需要把另一种工具链依赖加进来。
cargo编译：cargo.toml（项目依赖项，目标，版本）,也会检测config,toml里的指定覆盖编译器选项，默认行为。使用cargo.lock中的更精确版本。
开始下载依赖项。
任何一个项里有build.rs都会先执行。
从main.rs入口，根据里面use的顺序跳到其他的rs文件运行构建
链接。着重检查这里面和架构有关的地方。
假如有makefile那就是内部包含了更多对cargo的调用。