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

floor(), floorf(), ceil() and ceilf() Don't actually work on no-std (linker error) #258

Open
AldaronLau opened this issue Dec 12, 2021 · 7 comments

Comments

@AldaronLau
Copy link

The linker prints out: undefined symbol: fmodf and undefined symbol: fmod. I noticed that if I don't use any of these functions the linker error goes away. I've been trying to figure out why this is happening all day, and finally tracked it down to these functions. I believe the code that generates the code looking for this external symbol is caused by the force_eval!() macro invocation. To me it looks like maybe LLVM is trying to optimize based on that and attempting to use the actual libm.

It would also be nice if there was some documentation on what force_eval()! is for because I can't figure it out.

I'm running rustc 1.59.0-nightly (0b42deacc 2021-12-09) cross compiling from Linux (x86) to aarch64.

@Lokathor
Copy link
Contributor

force_eval!() is a questionable attempt to try and make the float operation happen at runtime rather than at compile time, so that the floating point flags are correct according to the spec.

What makes it questionable is that LLVM optimizes float ops as if there's no FP environmental flags anyway, so... it shouldn't actually affect anything to just remove all uses of the macro.

@Amanieu
Copy link
Member

Amanieu commented Dec 13, 2021

Aren't fmodf and fmod provided by this crate anyways? Why would it result in a linker error?

Can you provide example code to reproduce this issue?

@AldaronLau
Copy link
Author

@Amanieu yes, but they aren't #[no_mangle] so it can't find it. I tried, I am using it on no-std, and not super familiar with building standandalone apps on no-std so making example code has proven to be difficult. If you want to check the project in question, it's at https://github.com/ardaku/arc/tree/57b77f656088bc04f1fd8e3adb65db6ed3fb4566 - currently we're forcing it to link by defining empty functions in src/symbols.rs, but if they are removed then it fails to link.

@Amanieu
Copy link
Member

Amanieu commented Dec 13, 2021

fmod is re-exported by compiler-builtins with #[no_mangle], but only on a few specific targets. Perhaps we should expose a compiler-builtins-math feature that works like compiler-builtins-mem?

@YXL76
Copy link

YXL76 commented Apr 15, 2022

I also had this problem when compiling to target x86_64-unknown-none, cannot find fmax and fmin

@kevinaboos
Copy link

kevinaboos commented May 11, 2022

We have also experienced this issue on custom x86_64-based targets for quite a long time. My workaround has just been to write #[no_mangle] wrappers around the missing functions, but it'd be nice to have all of them exported correctly so linking works as expected. 👍

@HTGAzureX1212
Copy link

HTGAzureX1212 commented Jun 13, 2022

Just a heads up - I ran into this message myself quite some time before and went ahead to export all functions in this crate with #[no_mangle] and extern "C" for convenience, in a single crate: https://crates.io/crates/externc-libm

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

6 participants