You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi ... I am not sure I need to use this crate. I am trying to build a rust based static library to link with a RTOS embedded application. Unfortunately I get all sorts of duplicate item errors (primarily compiler_builtins) when linking the rust static library (.a file) when compiling and linking with the image for the embedded device.
I've found that if I emit objects and link in the .o of my rust library before cargo xbuild based command links in compiler_intrinsics then I can almost get my embedded application to build, I just have one undefined reference of __rust_probstack. If I manually add this function by copying code from the compiler_builtin's source to my rust code for the static library I can get my embedded application to compile and at least start execution. I'd like to properly link in select compiler_builtin functions into my static library (.a file) without manually adding the code for __rust_probstack, but I am not having luck doing that. After reading the description, I was wondering if I could fine tune which functions I used from compiler_builtins by adding this crate. However when I add to my rust code:
I get a lot of duplicate lang item errors such as:
error: duplicate lang item in crate `compiler_builtins`: `i128_add`.
|
= note: first defined in crate `compiler_builtins`.
Obviously I do not know my way around the rust build system very well. I am having trouble understanding which blogs and instructions I am following are already obsolete for what I am looking to do. In particular it seems compiler_builtins are built and linked automatically as part of libcore so I am not sure how bringing in this crate could not cause these type of linking errors. Can someone help my understanding here? Also I am not sure how/when to consider dependencies on the stage0 vs stage1 vs stage2 rust compiler but is that important to understand and apply here? In what direction do I need to look for these compiler intrinsic linking woes.
The text was updated successfully, but these errors were encountered:
jlb6740
changed the title
Duplicate lang item in crate 'compiler_builtins'. Do I need this crate?
Duplicate lang item in crate 'compiler_builtins'. Do I need this crate (Is the current README obsolete)?
Mar 14, 2019
tgross35
pushed a commit
to tgross35/compiler-builtins
that referenced
this issue
Feb 23, 2025
Hi ... I am not sure I need to use this crate. I am trying to build a rust based static library to link with a RTOS embedded application. Unfortunately I get all sorts of duplicate item errors (primarily compiler_builtins) when linking the rust static library (.a file) when compiling and linking with the image for the embedded device.
I've found that if I emit objects and link in the .o of my rust library before cargo xbuild based command links in compiler_intrinsics then I can almost get my embedded application to build, I just have one undefined reference of __rust_probstack. If I manually add this function by copying code from the compiler_builtin's source to my rust code for the static library I can get my embedded application to compile and at least start execution. I'd like to properly link in select compiler_builtin functions into my static library (.a file) without manually adding the code for __rust_probstack, but I am not having luck doing that. After reading the description, I was wondering if I could fine tune which functions I used from compiler_builtins by adding this crate. However when I add to my rust code:
and add to my cargo.toml:
Obviously I do not know my way around the rust build system very well. I am having trouble understanding which blogs and instructions I am following are already obsolete for what I am looking to do. In particular it seems compiler_builtins are built and linked automatically as part of libcore so I am not sure how bringing in this crate could not cause these type of linking errors. Can someone help my understanding here? Also I am not sure how/when to consider dependencies on the stage0 vs stage1 vs stage2 rust compiler but is that important to understand and apply here? In what direction do I need to look for these compiler intrinsic linking woes.
The text was updated successfully, but these errors were encountered: