Undefined scalbnf after switching to new emsdk 3.1.42 #19781
Comments
Honya2000
changed the title
|
My guess is that this actually broke in 3.1.41, and that the change that did it was the update of libc++/lib++abi in #19515. Can you confirm that 3.1.41 is also broken for you? |
|
Also, can you confirm if this is an LTO-specific issue? i.e. does it also happen when you build without |
|
Actually checked out to 3.1.41 and this fixed the issue. |
|
I'm trying to repro this locally and not having much luck. I've added some testing here: #19782 |
|
Seems likely to be related to #16836 (comment).. although the error message you are seeing here is very confusing since the |
|
See also #19774 |
|
Without lto the project compiled fine with emsdk 3.1.42 With -flto i have this observations: emsdk 3.1.41 generates libc.a of size: 6050348 bytes. As i mentioned earlier 3.1.41 links my project fine. I'm using this options to compile: My project is quite huge, so i cannot share it. Also i don't have much time for more deep investigations and creating small test cases. For now I have to stick to 3.1.41. |
|
Since you have a repro case, if you get time to look at this again, a useful task would be to try to try down which change in the 3.1.42 -> 3.1.42 range caused this issue. There are instructions for how to bisect on emsdk versions here: https://emscripten.org/docs/contributing/developers_guide.html#bisecting |
|
Tried to use sdk 3.1.44, the same error: I even tried workaround in my code: And now it reports the same error in my code. Probably there is some define with this name exists. But i didn't find it. |
|
tried to replace all scalbnf symbols to _scalbnf inside headers and sources of emsdk/upstream. wasm-ld: error: C:\Projects\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libc.a(scalbnf.o): undefined symbol: _scalbnf |
|
i give up. |
|
BTW you can get a lot of the benefits of LTO by building all your code with |
|
I'm using this cmake setup for the project: And during linking phase get this error: wasm-ld: error: C:\Projects\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libc.a(scalbnf.o): undefined symbol: scalbnf Not sure why it still uses lto libc.a. But sometimes ago i tried to compile my project without LTO at all. And it still reported the same error. Weird thing is that linker seems like expect referencing of scalbnf in the place where it is actually implemented. |
|
If the LTO version of libc is being used then
|
|
this is issued em++ command: FAILED: Release/bin/tmrwRooms-nt.js |
|
Will check later why lto still used during linking, but 100% this will not change anything. Because removing LTO in cmake didn't fix the issue one month ago. |
|
Yup there is the |
|
Back in #19781 (comment) you said removing LTO did fix the issue? Are you sure it doesn't fix it now? |
|
I said LTO didn't fix the issue one month ago. |
|
Will try to replace llvm binaries from 3.1.41 (but tomorrow). Because really looks like linker bug... |
|
Sorry, you right! disabling LTO for entire project in cmake - fixed the issue one month ago. |
|
Yes, i confirm, without lto - the project is compilable! |
|
Regarding my experiments with the binaries. In emsdk 3.1.44 today i replaced upstream/bin folder from emsdk 3.1.41. Anyway will have to rollback to 3.1.41... |
|
I can confirm that my project also breaks after switching to version > 3.1.41. Hope there will be a fix soon. |
|
My project is also breaks with Emscripten > 3.1.41. |
These plugins both use ldexp(), which delegates to scalbnf(). See emscripten-core/emscripten#19781 for the upstream bugreport.
These plugins both use ldexp(), which delegates to scalbnf(). See emscripten-core/emscripten#19781 for the upstream bugreport.
|
Another public test project: We face the same issue in Godot, described in godotengine/godot#80010. Edit: I've already worked it around with To reproduce the issue, with Emscripten setup: The It might take a while, especially the linking step as LLVM LTO doesn't use multiple threads, but eventually it fails with: Full build log with Emscripten 3.1.45: |
|
It sounds like this is a rather serious issue as it affects many projects, including Godot, Magnum, etc. To make sure I understand, it sounds like this is definitely an LTO issue as everyone here is using LTO? @sbc100 any idea what could be causing this? If not, would bisection help? Speaking of bisection, I tried to reproduce with the STR from the last comment, but @akien-mga I don't see an error on 3.1.42: Same with 3.1.45: (I did |
|
I'm also struggling to reproduce this. I tried the code produced by @Honya2000 in #19781 (comment) but I can't get it to fail. Does anyone have a simple repro case? |
That's because I already merged a workaround for this issue: godotengine/godot#81340 |
|
Simple repro case is below. Fails for me with 3.1.44, removing // em++ ldexp.cpp -o ldexp.js -flto
#include <cmath>
int main() {
return std::ldexp(3.0f, 3) >= 24.0f;
}
|
|
Thanks @mosra ! I bisected with that to this: Unfortunately a pretty long list landed there. I can bisect into that range, but @sbc100 I see you have a PR open already so maybe you know the cause of the regression already? |
|
You've got 4 commits directly related to |
|
(For anyone like me confused by the connection between |
|
Just to give more context on how I found that myself -- after seeing that none of the code on my end called Which looked way more likely to actually get called, and indeed the Not sure what exactly LTO does that it doesn't see the dependency between the functions. |
|
This problem can be solved by adding Read this: #16836 |
Thanks, adding |
Hello,
Today I switched to new emsdk 3.1.42 and unfortunatelly my project failed to compile now.
It throws error during linking:
wasm-ld: error: C:\Projects\emsdk\upstream\emscripten\cache\sysroot\lib\wasm32-emscripten\lto\libc.a(scalbnf.o): undefined symbol: scalbnf
The problem is i don't use any scalbnf in my project explicitly. But I'm using SDL2. And seems like SDL2 is using this function:
float
SDL_scalbnf(float x, int n)
{
#if defined(HAVE_SCALBNF)
return scalbnf(x, n);
#else
return (float)SDL_scalbn((double)x, n);
#endif
}
I cannot fix it in SDL2, because it is part of emsdk.
So what should i do now?
P.S. Previously i used emsdk 3.1.40 and everything was fine.
P.P.S in 3.1.41 and 3.1.42 release notes - no information about those changes. It just mentiones new LLVM version.
The text was updated successfully, but these errors were encountered: