Hi Sam,
   I see that error during runtime, when that branch of code is hit. Is 
there a way for them to atleast show up at load time so I can be sure that 
user wouldn't encounter any new errors in production?

On Saturday, 29 June 2019 01:17:22 UTC+5:30, Sam Clegg wrote:
>
> On Fri, May 31, 2019 at 1:25 AM Tapan Anand <[email protected] 
> <javascript:>> wrote: 
> > 
> > So does that mean its possible to miss some missing symbols as well 
> since runtime errors seems to be the only way to determine them? 
>
> Yes, they are currently runtime errors, because dynamic linking 
> happens at runtime.   Are you seeing them show at at startup or after 
> main runs?   We should at least be able to ensure these are load time 
> errors. 
>
> Ideally we would build a system where the MAIN_MODULE and the 
> SIDE_MODULE can be built in such a way that can know that list of 
> symbols needed by the other modules.  However because we have a lot of 
> circular dependencies this could prove a little tricky. 
>
> > 
> > On Friday, 31 May 2019 03:49:27 UTC+5:30, Alon Zakai wrote: 
> >> 
> >> Yes, in general the optimizer may remove anything it does not see is 
> used, in normal compilation, and in main module/side module mode 2. It's 
> possible some things stay alive anyhow since they are used by other things. 
> But if nothing else uses it, you must add it to the exports yourself, or 
> the optimizer may remove it. 
> >> 
> >> On Wed, May 29, 2019 at 1:10 PM Tapan Anand <[email protected]> 
> wrote: 
> >>> 
> >>> Thanks for the quick reply Alon! 
> >>> The C library functions puts and printf work with MAIN_MODULE=1 but 
> the new and delete operator errors still persist if I don't manually export 
> them. 
> >>> Regarding - "which means you need to carefully pick what is kept alive 
> for the other modules", so you mean we have to add these mangled names in 
> the export list if we use MAIN_MODULE=2 and there is no other way to avoid 
> this? MAIN_MODULE=1 creates a huge .js and .wasm file and hence ends up 
> increasing the MAIN_MODULE size while the purpose of dynamic linking for me 
> is to reduce its size. 
> >>> Also, I got to know about new and delete via runtime errors, but what 
> if I some part of code is not encountered while testing (and hence no 
> runtime error occurs)? That may cause unknown crashes when the user uses 
> the app for example, is that expected? Or there is a way to know unresolved 
> symbols in advance using some technique? 
> >>> 
> >>> On Thursday, 30 May 2019 00:00:45 UTC+5:30, Alon Zakai wrote: 
> >>>> 
> >>>> This is probably because of MAIN_MODULE=2, which means you need to 
> carefully pick what is kept alive for the other modules. Does this work 
> with =1? If so then that's the issue. The test suite has a bunch of 
> examples for mode 2, that might help. 
> >>>> 
> >>>> On Wed, May 29, 2019 at 3:40 AM Tapan Anand <[email protected]> 
> wrote: 
> >>>>> 
> >>>>> Hi, 
> >>>>> 
> >>>>> I was trying to use dynamic linking using dlopen with emscripten 
> compiler version 1.38.28 and encountered the following problem: 
> >>>>> 
> >>>>> 1. When I try to use vector in the SIDE_MODULE, it can't seem to 
> find the new and delete operators in the Module variable. 
> >>>>> 
> >>>>> 2. The command I use to build main and side module are: 
> >>>>> 
> >>>>> 
> >>>>> em++ doubler.cpp -o doubler.wasm -s SIDE_MODULE=1 -O3 -s 
> "EXPORTED_FUNCTIONS=['_doubler']" 
> >>>>> EMCC_FORCE_STDLIBS=1 em++ main.cpp -O3 -s WASM=1 -s MAIN_MODULE=2 -o 
> dynlink.js -s "EXPORTED_FUNCTIONS=['_main', '_clock', '_tripler', 
> '_printf', '_puts']"  -s "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=['clock']" -s 
> FORCE_FILESYSTEM=1 --pre-js prejs.js 
> >>>>> 
> >>>>> 
> >>>>> The prejs file here is there to use FS.createLazyFile to cause lazy 
> loading of the side module. 
> >>>>> 
> >>>>> If I change the exported function list in main_module to `['_main', 
> '_clock', '_tripler', '__Znwm', '__ZdlPv', '_printf', '_puts']` It starts 
> to work. Notice that I had to add the mangled symbols of new and delete 
> operator to export list. 
> >>>>> Also, once I did this, I didn't get any missing symbols related to 
> the vector class itself. 
> >>>>> 
> >>>>> So, I have two questions: 
> >>>>> 1. Do we have to export C++ runtime functions like new, delete, or 
> even c runtime methods like printf, puts for code to work? Is that 
> expected? 
> >>>>> 2. Since there were no errors for vector related symbols, does that 
> mean that vector is linked with the side_module? If I also use vector in 
> main module, will there be effectively two copies of vector? In both side 
> and main module? 
> >>>>> 
> >>>>> Thanks in advance! 
> >>>>> 
> >>>>> -- 
> >>>>> You received this message because you are subscribed to the Google 
> Groups "emscripten-discuss" group. 
> >>>>> To unsubscribe from this group and stop receiving emails from it, 
> send an email to [email protected] 
> <javascript:>. 
> >>>>> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/5f2ad4c5-fc8e-45a3-afab-e340f91f09f5%40googlegroups.com.
>  
>
> >>>>> For more options, visit https://groups.google.com/d/optout. 
> >>> 
> >>> -- 
> >>> You received this message because you are subscribed to the Google 
> Groups "emscripten-discuss" group. 
> >>> To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email protected] <javascript:>. 
>
> >>> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/058436c9-50d5-4a13-a499-cbca19214066%40googlegroups.com.
>  
>
> >>> For more options, visit https://groups.google.com/d/optout. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "emscripten-discuss" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email protected] <javascript:>. 
>
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/emscripten-discuss/f5c8beed-0aee-4a0f-8748-17321afb48dd%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/e30016f3-0de3-4d3f-9c35-538b4f58e6db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to