On Fri, May 31, 2019 at 1:25 AM Tapan Anand <[email protected]> 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].
>>>>> 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].
>>> 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].
> 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/CAL_va2-1yy9fwyUq5LYL9HML%3Dnt8GDUhUreyAkxgTTh6xzSjcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to