Do emscripten support backward compatibility? #20743
Replies: 3 comments
-
From your question it sounds like you mean backwards compatibility of building a project with emscripten (as opposed to, say, backwards compatibility of dynamic libraries or something else). In general we try not to break backwards compatibility in that sense. Rarely, we allow a breaking change when it is necessary for a worthwhile improvement, like fixing a long-standing cause of code size bloat. When breaking changes happen, they are mentioned in the Changelog, so reading that for relevant entries might help. We also try to add useful runtime error messages for such changes, when you build with assertions (a non-optimized build). |
Beta Was this translation helpful? Give feedback.
-
If you use matching versions do the issue go away? Its not inconceivable that you are running into an object file version-compatibility issue, but it should be easy to enough to check one way or the other but trying with matching versions. In general its always best to avoid sharing object and libraries between versions of emscripten and instead always try to rebuild everything from source when you change emscripten versions. |
Beta Was this translation helpful? Give feedback.
-
Thanks for reply, I compile ncnn with 3.1.28, results of the paddleocr on browser still looks weird, not sure what happened, maybe a bug of ncnn webassembly(works very well on desktop) |
Beta Was this translation helpful? Give feedback.
-
As the title mention, do it support backward compatibility? If there is no guarantee, do I have a way to find out which version break the compatibility? I may need to mix 3.1.28 and 3.1.25 together, because Qt6.5.2 asked for 3.1.25, but ncnn is using 3.1.28.
I am using ncnn-20231027 compiled with 3.1.25, it give me weird results when using paddleocr v3
Beta Was this translation helpful? Give feedback.
All reactions