无法构建no_std的rust项目 #4929
Comments
Title: Unable to build no_std rust project |
|
实际上的话会有两个问题，如果我使用 因为xmake会使用main.rs编译可执行文件，因为找不到 然后，如果试图用 这里is_cross()会为真，但是这个是cargo的源而不是xmake的package manager所以两个分支都不会执行。 |
|
去掉 |
If |
|
等节后我看下，最近忙不过来 |
I'll check it out after the holidays, I've been too busy lately |
|
I had similar problems with Basically it changes |
这个只是个空 wrapper ，仅仅只是为了借助 cargo 拉取到对应的依赖库，而这个编译生成的二进制产物 不会去使用。
能否给个完整的 project demo ，我调试下
xmake 里 rust 项目不是用 cargo 编译的，是 xmake 自己直接调用 rustc 编译的。。调用 cargo 仅仅只是为了拉依赖库 如果都直接调用 cargo 去编译项目了，那就没 xmake 啥事了，你直接用 cargo 去编译就完事了，没必要去用 xmake 或者可以看下这个 https://docs.rs/xmake/latest/xmake/，在 cargo 里调用 xmake |
This is just an empty wrapper, just to use cargo to pull the corresponding dependent library, and the binary product generated by this compilation will not be used.
Can you give me a complete project demo so I can debug it?
The rust project in xmake is not compiled with cargo, but is compiled by xmake itself directly calling rustc. . Calling cargo is just to pull dependent libraries If you call cargo directly to compile the project, then there is no need for xmake. You can just use cargo to compile it. There is no need to use xmake. Or you can take a look at this https://docs.rs/xmake/latest/xmake/ and call xmake in cargo |
我又想了一下应该是编译出来了，x86_64-unknown-none的主要问题可能是x86_64-unknown-none和x86_64-linux-gnu会被xmake认为是两个架构没法链接在一起，等我去看的时候他已经把东西删了。所以就算强行install了之后编译rust项目的时候用的tuple还是错的。 https://github.com/Yangff/xmake_rust_no_std 但是，如果去掉 不知道为什么他会尝试链接main，明明我设置了 https://github.com/Yangff/xmake_rust_no_std/tree/linux-no-std |
rust那边我可以生成正常的 |
I can generate normal |
|
这边试了下，似乎编译 talc 就报错了，是我这 ructc 版本太低了？ xmake 在提取 dep 时候会自动生成一个 stub 项目。你可以直接把这个 project 搬出来，看看执行 cargo build 能否编译过。。 cd ./build//.packages/c/cargo_rsystem/latest/cache/source/
cargo build -vv |
应该是，allocator api还是nightly。你可以 |
It should be, allocator api or nightly. you can |
|
可能要把 #[panic_handler]
#[cfg(not(test))]
fn panic(_info: &core::panic::PanicInfo) -> ! {
loop {}
}
// rust_eh_personality
#[no_mangle]
#[cfg(not(test))]
extern fn rust_eh_personality() {}这个加上 |
|
不过就算不加，用了nightly的话我这里也可以进到这一步 master （这里因为我改了install的逻辑）: |
|
我更新到 nightly 并且用了你那个 main demo，报了其他错误，直接 cargo build 时候 $ rustc --version
rustc 1.80.0-nightly (84b40fc90 2024-05-27)
$ cargo --version
cargo 1.80.0-nightly (a8d72c675 2024-05-24)
$ cargo build -vv
error[E0152]: found duplicate lang item `panic_impl`
--> src/main.rs:3:1
|
3 | / fn panic(_info: &core::panic::PanicInfo) -> ! {
4 | | loop {}
5 | | }
| |_^
|
= note: the lang item is first defined in crate `std` (which `rsystem` depends on)
= note: first definition in `std` loaded from /Users/ruki/.rustup/toolchains/nightly-x86_64-a
pple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-376bcbded3bf48cc.dylib, /Users/ruki/.rus
tup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-376bcbded
3bf48cc.rlib
= note: second definition in the local crate (`rsystem`)
|
master 分支请使用 linux-no-std分支请使用： |
|
master分支是演示如果将目标的arch设置成 不过我不是很确定的一点是无论如何也不应该出现 我试了一下加不加panic函数我这里都是能编译的才对。。 |
|
而且不管怎么说我配置的也是 不应该出现main吧？ |
And no matter what, I configured it with Main shouldn't appear, right? |
|
linux-no-std分支在configure的时候失败 master分支似乎可以正常xmake f了（不确定是不是我改了什么代码的结果），但是xmake报的错误是 加上 |
master 我这也可以了
target 这个我加上了，你可以再试试 #5164 xmake update -s github:xmake-io/xmake#rustpanic 这个需要用户手动自己加上吧，那这边就不管了。。我加上后也能编译 不过我这 macOS 上 link 的时候，还有一个 error 正在看。 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-o build/macosx/x86_64-unknown-none/release/libtest.dylib build/.objs/test/macosx/x86_64-unknow
n-none/release/src/main.c.o -shared -target x86_64-unknown-none-apple-macos14.0 -isysroot /Appl
ications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -
lz -fPIC -Lbuild/macosx/x86_64-unknown-none/release -Wl,-x -Wl,-dead_strip -lrsystem -install_n
ame @rpath/libtest.dylib
ld: archive member '/' not a mach-o file in '/Users/ruki/Downloads/xmake_rust_no_std/build/maco
sx/x86_64-unknown-none/release/librsystem.a' |
我单独拎出来用 cargo build 也一样失败，因为你配置了 no main ，所以内部那个 stub rs 里面，自动加了 $ cargo build --release -vv
defaultlibs"
= note: ld: Undefined symbols:
_main, referenced from:
<initial-undefines>
clang: error: linker command failed with exit code 1 (use -v to see invocation)没有 main 就 link 失败了。。所以，我刚提 cargo deps 的那个 stub wrapper 改成 staticlib 了，这样里面就不会走到 link ，反正也只是为了提取 cargo 下载的依赖用。。 再试试，至少 main link 那个问题，应该能过掉了。 |
|
mater可以正常编译了 linux-no-std那边还需要加上
看起来c项目的target和rust的target不一致，链接的时候选择的target是 不过LLVM的triple太乱了，rust的更乱，感觉这里除了一坨if下来没啥特别好的拼接方法其实。 |
linux-no-std 你这新 patch 还是不行么，什么错误？ |
linux-no-std Is your new patch still not working? What is the error? Is |
arch 拼错这个问题，主要是你这 set_arch 全局配置导致的，会对 test target 也生效，但是 test target 里面只有 .c 文件，属于 c 项目，走的 xcode toolchain ，这个时候设置的 arch 应该得用默认的 x86_64 ，而不是 rust 那个 x86_64-unknown-none 你只能单独对 rust 那个 target ，和它的 package 配置 x86_64-unknown-none add_requires("cargo::rsystem", {
arch = "x86_64-unknown-none",
configs = {
std = false,
main = false,
cargo_toml = path.join(os.projectdir(), "rsystem", "Cargo.toml"),
}
})
target("rsystem")
set_kind("static")
add_files("src/lib.rs")
set_values("rust.cratetype", "staticlib")
add_packages("cargo::rsystem")
set_arch("x86_64-unknown-none")这样，arch 就不会拼错了，但是我这那个 error 还不是这个 arch 导致，问题还是存在 |
可以，只是要自己加上这个 一般如果整个项目都是 no_std 的且目标是 这里的问题是，cargo.toml里面的定义只是对crate而言的，也就是说crate是no_std而项目本身链接std是完全可能的（一些库用不到std的东西就可以加上这个）。所以应该是没没办法简单根据crate的情况来决定是不是要加这行。 |
Yes, you just need to add this Generally, if the entire project is no_std and the target is The problem here is that the definition in cargo.toml is only for crate, which means that the crate is no_std and it is entirely possible for the project itself to link to std (some libraries can add this if they do not use std). So there should be no way to simply decide whether to add this line based on the crate situation. |
|
如果不加的话会这样 |
既然默认也是 abort ，那我就全局加了。。你再试试那个 patch ，看看还有啥问题，没得话，我先 merge 了 |
啊不是的， 但是如果只是根据说cargo包是no std就说整个项目也是no std好像是不大对劲的。。但也不好说，毕竟xmake这里似乎就是把这个cargo包当成是项目本身的cargo.toml来用那好像又没问题。。反正我是不大确定这里到底是咋回事了（ |
这个patch是能用了，不过是否加panic的条件我觉得可以考虑一下，或者单独给一个配置项？至少正常的项目是不应该加这个的，全加上应该会坏事…… 只有真正的no_std项目需要这个（不包括那些只是某个包需要no_std的，比如会不会有人add_requires哪个crate的时候拉进来一个no_std的包）. |
Since the default is also abort, I will add it globally. . You can try that patch again and see if there are any problems. If it doesn't work, I'll merge it first. |
This patch can be used, but I think we can consider whether to add panic conditions, or provide a separate configuration item? |
Ah, no, But it seems wrong to say that the entire project is also no std just based on the cargo package being no std. . But it’s hard to say. After all, xmake seems to use this cargo package as the cargo.toml of the project itself, so there seems to be no problem. . Anyway, I’m not quite sure what’s going on here ( |
关键是这边没法判断当前项目是否 no_std，只有某个包有这个配置，target 里面判断不出来，除非根据 arch 判断是否交叉编译，如果交叉编译就加。。 再不行，就只能用户自己 add_rcflags 自己加了 |
The key is that there is no way to determine whether the current project is no_std. Only a certain package has this configuration. It cannot be determined in the target unless it is judged according to arch whether to cross-compile. If it is cross-compiled, add it. . If it doesn't work, the user can only add it by himself using add_rcflags. |
尴尬的是交叉编译的那个情况反而不用加就行了，因为走的是-none的triple，rustc自动就是abort。 我觉得在target这个范围内好像没有特别好的条件来判断。。 |
The embarrassing thing is that in the case of cross compilation, there is no need to add it, because using the -none triple, rustc automatically aborts. I feel like there are no particularly good conditions to judge within the scope of target. . |
我改进过了，再试试，现在直接解析 .rs 里面的 [no_std] 来判断是否 no_std 了。 |
I have improved it and will try again. Now I can directly parse [no_std] in .rs to determine whether it is no_std. |
|
我 merge 了，先这样吧，有问题再开 |
I have merged. Let’s leave it like this for now. If there are any problems, we’ll open it again. |
可以了 |
That's it |
Xmake 版本
xmake v2.8.9+20240321
操作系统版本和架构
linux 6.7.3
描述问题
我试图在一个C+rust的项目里使用no_std/nostdlib(可以先忽略C的这部分) 进行编译。
rust项目在独自的rsystem目录下，有自己的xmake.lua。
我使用
add_requires("cargo::rsystem", {...})为它添加std = false, main = false并使用toml管理它的cargo依赖。这个库应该被编译为静态库并可以被c链接。
遇到的问题首先
rsystem这个目标似乎会被编译成可执行文件，xmake为它生成的Cargo.toml并不会包含[lib]，并且xmake会为它会生成一个main.rs（里面似乎还包含一些panic handler之类的东西，但这不应该是我自己添加吗？）而不是lib.rs进行编译。其次，xmake无法正确安装编译产物，在提示
copy /home/dell/Projects/test-proj/build/.packages/c/cargo_rsystem/latest/cache/source/target/x86_64-unknown-none/release/deps to /home/dell/Projects/test-proj/build/.packages/c/cargo_rsystem/latest/934c937479bb4bedb432f28382ca4aaa/lib之后，复制并没有成功，在目标路径并不存在，尽管源文件的路径确实存在。仔细看了一下，在installdir.failed/lib 里面是有这些文件的
另外有一个疑问是，我预期的行为是整个项目被cargo原封不动地进行编译，然后和项目的其他部分进行链接，但是似乎xmake会创建一个额外的cargo项目然后只包含我
add_files("src/lib.rs")添加的lib.rs？期待的结果
编译得到一个static library并可以被添加为其它c项目的依赖项（这里没有使用 bindgen，因为我打算手写头文件）
工程配置
在
rsystem/xmake.lua中其中cargo.toml的内容为
根目录的xmake.lua
lib.rs
alloc.rs
附加信息和错误日志
另外单独安装cargo package也是失败的
例如：
错误是一样的，都是拷贝之后提示
error: .../modules/private/action/require/impl/actions/install.lua:398:The text was updated successfully, but these errors were encountered: