Skip to content

Conversation

@LGFae
Copy link

@LGFae LGFae commented Oct 5, 2025

We can make the crate work in #![no_std] environments with minimal changes. Literally just changing a few imports.

Should be trivial to maintain as well, just make sure to always import from core rather than std. I could maybe try adding a no_std test to make sure the codegen always compiles in no_std environments, if necessary.

LGFae added 3 commits October 5, 2025 17:51
We can make the crate work in `#![[no_std]]` environments with minimal
changes. Literaly just changing a few imports.
When we do not use `std`, we cannot load things dynamically with
`libloading`. By its very nature, `libloading` will probably always
include a lot of platform-specific code, making it not depend on `std`
unrealistic. So, when someone says they do not want to use `std`, we
should not use `libloading`. As long as downstream does not try to
dynamically load something with `default-features=false`, this should
never be a problem.

What happens if downstream does try that, however? Well, then the Rust
compiler with print an error saying they are trying to use a crate that
does not exist. Because we default to using `std` (as is the standard
for most optionally `no_std` crates), this should not cause any
breakage.
@LGFae
Copy link
Author

LGFae commented Oct 5, 2025

Update: I realized this is less trivial than I first thought, because of this crate's dependency on libloading.

I have implemented a flag such that we only use libloading if std is active. The downside is that dlib cannot use dlopen in no_std environments, and can only support linking directly. I documented this behavior in the top-level doc comment.

I still believe this can be useful, as libraries downstream will be able to support no_std environments, even if with limitations. That said, I can understand if maintainers of this project do not wish to include this.

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

Successfully merging this pull request may close these issues.

1 participant