Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile with rust TCLIBC different from the project default #155

Open
andrey-eero opened this issue Oct 17, 2023 · 6 comments
Open

Compile with rust TCLIBC different from the project default #155

andrey-eero opened this issue Oct 17, 2023 · 6 comments

Comments

@andrey-eero
Copy link

By default my yocto project use TCLIBC="gnu". However I need to compile fully static rust app using TCLIBC="must"
Is there a way to setup rust toolchain different from (or additional to) the default target TCLIBC?

I soled it introducing RUST_TCLIBC="musl" and patching classes/rust-common.bbclass like this.

-    tclibc = d.getVar("TCLIBC", True)
+    tclibc = d.getVar("RUST_TCLIBC", True)
+    if tclibc == "":
+        tclibc = d.getVar("TCLIBC", True)

Is there a way to do this without patching rust-common.bbclass? Can we introduce RUST_TCLIBC variable to defining TCLIBC for rust?

@nick-owens-eero
Copy link

@posborne do you have any opinions about the best way to fix this? we'd like to build binaries using rust with musl using this layer.

@posborne
Copy link
Member

@nick-owens-eero Sorry this got buried, I don't have extensive experience here but one approach we've used in the past is to achieve this using multiconfig. Dealing with multiconfig can be a pain and I can't provide simple instructions for exactly what you'll need for your case, but looking at back we've been able to just add this to the recipe:

BBCLASSEXTEND += "mcextend:musl"                                                                                                                                  

With a multiconfig in our conf for musl configured as needed by our use case, yours may be different depending on where/how/etc. you are embedding the musl artifacts. When Yocto is building the recipe with the mc variant, it will set TCLIBC to what is defined in the multiconfig config for "musl" in this case.

Here's an example of a conf/multiconfig/musl.conf:

TCLIBC = "musl"                                                                                                                                              
TMPDIR="${MULTICONFIG_TMPDIR}"                                                                                                                               
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"                                                                                                            

There's a lot more moving pieces for using these artifacts and pulling them into an image (it gets messy) but that's mostly mc messiness rather than what I currently view as being a meta-rust-bin issue a this time.

@andrey-eero
Copy link
Author

andrey-eero commented Feb 21, 2024

@posborne Actually the main issue we have is that rust toolchain that is required for a specific project (must TCLIB) is not installed. That would be really helpful if we could specify list of toolchain we want to use in some variable. Or have a way to override automatically detected tollchain. For now we are trying to detect automatically what toolchain do we need.

@andrey-eero
Copy link
Author

@posborne Actually my fix allows to override the automatically detected TCLIBC

@posborne
Copy link
Member

@andrey-eero Right, I understand the patch. The issue I see and acknowledge it probably works fine for simple cases. Where things become problematic, I think, is when the recipe being built starts to have DEPENDS on other recipes. In that case, without use of multiconfig, you'll have a mix of TCLIBC between (in this case) glibc and musl that is likely going to cause problems. AFAIK, multiconfig is the mechanism in Yocto designed for supporting this case.

@posborne
Copy link
Member

@nastevens Correct me if my understanding of multiconfig here is off or you have other thoughts. This is a problem we struggled with solving seamlessly for our use cases from my recollection but still not convinced one-off overriding the rust libc is the best route either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants