-
Notifications
You must be signed in to change notification settings - Fork 27
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
[Feature Request]: Discuss the move to static instead of shared build for wasm use cases #493
Comments
Now describing how you get a static build
I am pasting the full file (not the diff but the full file for |
|
@anutosh491 Thanks for raising this issue. I'll look at it in more detail the weekend. My initial comments are we want the cmakelist.txt to be of the structure (to support both the ability to build a shared library and static library)
You've renamed the target clangCppInterOp to CppInterOp for your static build. Please return back to the original target name, as when we get testing working they assume that target name, and allows consistency between wasm and non wasm builds. Next you set link_libs to clangInterpreter. Please set this to ${cling_clang_interp} (this was a mistake with the shared library build which I missed in the review). One final comment when I haven't tried using this static llibrary with xeus-cpp yet, but when I tried to link it to see if it would work with the automated tests work I got a large number of undefined symbols coming related to llvm (being it hit the error limit non appeared to be coming from CppInterOp). When I ran into this issue with the shared library build I fixed it with the '--export-all' linker flag. I will provide a copy of these symbols tomorrow. |
As far as ideas I have for optimisations here are some my initial thoughts for improving the shared library build. We used SIDE_MODULE=1 . This assumes you want to export all default symbols, while for SIDE_MODULE=2 you choose what you do and do not think needs exporting assuming I understand the flag correctly (assuming I understand this comment correctly emscripten-core/emscripten#16762 (comment)). By default emcc builds with no optimisations https://emscripten.org/docs/optimizing/Optimizing-Code.html . It would come at the cost of a longer build but maybe we could try the -O2,-O3 or -Os flag for release builds. |
@vgvassilev pinging for comment on this issue.To me it doesn't make sense to completely remove the ability to build a wasm shared library for CppInterOp, given all the efforts to get something which works. Rather I think it makes sense to have the ability to build both. I don't mind the static build being the default, but doesn't seem to make sense (at least not to me) to completely remove the shared build. |
Well, I don't see anyone write that we need to completely get rid of anything anywhere. The issue title reads "Discuss" the move to static instead of shared build 😅 I really like the shared build as it works perfectly for xeus-cpp-lite (going against the idea that emscripten doesn't really recommend shared builds) The general idea with wasm is that mostly people prefer static linkages because shared libraries are fragile. At least they make more problems and are harder to handle at runtime .... but we probably don't make the move untill we have good enough concrete proof to do so. My take here is
Our focus for now shouldn't be on making the move or not .... getting rid or not .... rather finding concrete evidence/usecase on which is better. |
Maybe it was me misunderstanding the title. My understanding was from the words 'instead of' and your cmakelists.txt only showing a static build in it. I'm all for recommending to the user that they use a static build if it turns out to be better. It is possible and and relatively straight forward (at least as far as CppInterOps repo is concerned) to have a single deployment, where you can switch between the 2 builds, so we can test them side by side (only publically providing a link to the one deployment that we think is best). The dual version deployment would help those developing. |
Yeah whatever works. My point here is that theoretically every package out there can support a static build and a shared build but I never see a package maintaining both of them. They double down on the better one. So nothing wrong with having the two and keeping them. The problem rather is we haven't found the better one. And once we have that we need to focus on improving it ! |
As a first step i'll look into this in more detail, and get back to you (hopefully in the next week) |
I agree we need to support static builds. Our current static builds include transitive dependencies I think. The downside is that the binary sizes of the static builds. Another current problem I think is that we can only resolve symbols from shared libraries from the Jit. That’d mean that we should put all possible packages into that static binary which will make it even harder to download. Let’s use static libraries but I am not quite sure if we can match the functionality shared libraries have at that point in time… |
Description of new feature
Hey All,
Currently we have a decent shared wasm build for cppinterop. By decent I mean the following
i) somewhat optimized, takes around 15 mins to build
ii) Not too shabby and clear of obvious warnings
iii) Xeus-cpp-lite build time is not too long takes around 1 min 10 seconds using libclangCppInterOp.so
iv) After introducing the following lines in xeus-cpp, Jupyterlite knows we xeus-cpp needs access to libclangCppInterOp.so at runtime and hence there hasn't been any issues running stuff with latest jupyterlite-core
But the general notion with emscripten is that static libs are generally preferred. Pyodide and emscripten-forge avoid shared libraries as much as possible and only use them if the static build doesn't work. Infact, Cmake + emscripten don't even provide a way to generate a shared build. Read emscripten-core/emscripten#15276
So we introduce a work around to get our shared builds. Hence as move to emsdk 3.1.73 (through #456) we should be able to generate a static build (which was not possible with 3.1.45 ... check llvm/llvm-project#114651)
But there is things to discuss before we do that
libclangInterpreter.a
like we do currently forlibclangCppInterOp.so
)The text was updated successfully, but these errors were encountered: