Regression: libfunty expecting libm in #![no_std] even with default-features disabled

[asoderman]

I am unable to get this crate to compile in a #![no_std] environment due to the linker failing to locate various floating point functions provided by libm.

Here is my Cargo.toml entry:

bitvec = { version = "1", features = ["atomic", "alloc"], default-features = false }

and the linker errors:

= note: rust-lld: error: undefined symbol: fmaxf
          >>> referenced by f32.rs:692 (/home/alex/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/f32.rs:692)
          >>>               funty-da8ab0dd9fd4a525.funty.49932917-cgu.2.rcgu.o:(core::f32::_$LT$impl$u20$f32$GT$::max::h473bee7476e3f8c8) in archive /home/alex/Development/kernel/target/x86_64-bare/debug/deps/libfunty-da8ab0dd9fd4a525.rlib

          rust-lld: error: undefined symbol: fminf
          >>> referenced by f32.rs:712 (/home/alex/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/f32.rs:712)
          >>>               funty-da8ab0dd9fd4a525.funty.49932917-cgu.2.rcgu.o:(core::f32::_$LT$impl$u20$f32$GT$::min::h61b16a3857045f2f) in archive /home/alex/Development/kernel/target/x86_64-bare/debug/deps/libfunty-da8ab0dd9fd4a525.rlib

          rust-lld: error: undefined symbol: fmax
          >>> referenced by f64.rs:708 (/home/alex/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/f64.rs:708)
          >>>               funty-da8ab0dd9fd4a525.funty.49932917-cgu.0.rcgu.o:(core::f64::_$LT$impl$u20$f64$GT$::max::hddf19d8f0ae889a3) in archive /home/alex/Development/kernel/target/x86_64-bare/debug/deps/libfunty-da8ab0dd9fd4a525.rlib

          rust-lld: error: undefined symbol: fmin
          >>> referenced by f64.rs:728 (/home/alex/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/f64.rs:728)
          >>>               funty-da8ab0dd9fd4a525.funty.49932917-cgu.0.rcgu.o:(core::f64::_$LT$impl$u20$f64$GT$::min::h931702728a5b659b) in archive /home/alex/Development/kernel/target/x86_64-bare/debug/deps/libfunty-da8ab0dd9fd4a525.rlib

Would it be possible to feature-gate off the floating point parts of libfunty (I'm assuming this crate does not use floating point 😄 )?

[myrrlyn]

Floating point functions continue to be my long-standing nightmare. Thank you for bringing this to my attention; while I do test against freestanding targets, it looks like you're using one I haven't seen before?

I haven't tried to demangle those symbols, but I would guess that they're trying to reach core::f32::<impl f{32,64}>::{max,min}, which forward to core::intrinsics::{max,min}numf{32,64}. These don't have any target gating on them, which means those intrinsics are always available and should always try to link against some implementation, either in libm or in the ongoing compiler-intrinsics work.

I can look into putting more gates in funty, but since right now it follows the existing core/std distinction for known targets, I would guess that funty just happened to be a symptom of something else going on with your target? I'm uncertain.

I think the fastest immediate resolution for you would be to vendor funty locally and just delete the floating-point sections. You're right, bitvec doesn't use them.