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?

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] 
> <javascript:>> 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].
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/emscripten-discuss/5f2ad4c5-fc8e-45a3-afab-e340f91f09f5%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/emscripten-discuss/5f2ad4c5-fc8e-45a3-afab-e340f91f09f5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> 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
>>  
>> <https://groups.google.com/d/msgid/emscripten-discuss/058436c9-50d5-4a13-a499-cbca19214066%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> 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/f5c8beed-0aee-4a0f-8748-17321afb48dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to