Skip to content

wasm-ld: ....o: undefined symbol: ldexp in Release modes, but works in Debug #23358

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

Open
barathrm opened this issue Mar 25, 2025 · 1 comment · May be fixed by #24142
Open

wasm-ld: ....o: undefined symbol: ldexp in Release modes, but works in Debug #23358

barathrm opened this issue Mar 25, 2025 · 1 comment · May be fixed by #24142
Labels
bug Observed behavior contradicts documented or intended behavior compiler-rt contributor friendly This issue is limited in scope and/or knowledge of Zig internals.
Milestone

Comments

@barathrm
Copy link

Zig Version

0.15.0-dev.99+c1db72cdb

Steps to Reproduce and Observed Behavior

Tried finding existing reports or similar issues, but no luck. Apologies if there's an existing one I couldn't find.

Found while trying to build dvui for wasm32-freestanding in ReleaseSafe mode, which fails, but which works in Debug mode. The smallest reproducible snippet I could find is

// test.zig
export fn bla(f: i32) f64 {
    return @exp2(@as(f64, @floatFromInt(f)));
}

Then

$ zig build-exe -target wasm32-freestanding -O Debug -fno-entry -rdynamic test.zig 
$ echo $?
0
$ zig-0.15.0-dev build-exe -target wasm32-freestanding -O ReleaseSafe -fno-entry -rdynamic test.zig 
error: wasm-ld: test.wasm.o: undefined symbol: ldexp

Changing the argument from i32 to i64 makes it pass:

export fn bla(f: i64) f64 {
    return @exp2(@as(f64, @floatFromInt(f)));
}

Changing the integer to i32 argument and the floats to f32 makes it fail on undefined symbol: ldexpf.

Expected Behavior

I expected a build which succeeds in Debug to also succeed in any of the release build modes.

@barathrm barathrm added the bug Observed behavior contradicts documented or intended behavior label Mar 25, 2025
@alexrp
Copy link
Member

alexrp commented Mar 25, 2025

This is happening because of LLVM's LibCallSimplifier; it seems to assume that ldexp exists when simplifying exp2. Same story for ldexpf.

We should just add ldexp/ldexpf/ldexpl implementations in Zig's compiler-rt for use when libc doesn't provide them, similar to what we do with exp2/exp2f/exp2l.

@alexrp alexrp added compiler-rt contributor friendly This issue is limited in scope and/or knowledge of Zig internals. labels Mar 25, 2025
@alexrp alexrp added this to the 0.15.0 milestone Mar 25, 2025
th3james pushed a commit to th3james/zig that referenced this issue May 23, 2025
Enough to make ziglang#23358 snipped pass
th3james pushed a commit to th3james/zig that referenced this issue May 28, 2025
Enough to make ziglang#23358 snipped pass
th3james pushed a commit to th3james/zig that referenced this issue May 28, 2025
th3james pushed a commit to th3james/zig that referenced this issue May 29, 2025
th3james pushed a commit to th3james/zig that referenced this issue Jun 2, 2025
th3james pushed a commit to th3james/zig that referenced this issue Jun 3, 2025
th3james pushed a commit to th3james/zig that referenced this issue Jun 6, 2025
th3james pushed a commit to th3james/zig that referenced this issue Jun 6, 2025
th3james pushed a commit to th3james/zig that referenced this issue Jun 8, 2025
th3james pushed a commit to th3james/zig that referenced this issue Jun 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior compiler-rt contributor friendly This issue is limited in scope and/or knowledge of Zig internals.
Projects
None yet
2 participants