Any code that participates in dynamic linking needs to be built with
either SIDE_MODULE or MAIN_MODULE.

You probably want to be compiling your loader.c/main.c with
MAIN_MODULE and all the others with SIDE_MODULE.

On Thu, May 30, 2019 at 5:44 AM J Decker <[email protected]> wrote:
>
> https://gist.github.com/d3x0r/ca3cef9a5fc9124dd1f43a94ce098b5b
>
> This gist approximately demonstrates what I'm doing.
> In my main code I'm getting 'undefined reference to '_free'' which IS 
> exported in the libcore equivalent...
>
> The error that script is generating is...
>
> ```
> M:\sack\amalgamate\wasmgui\testlink>call emcc  main.c -L. -lc.wasm -o 
> main.wasm
> emcc:WARNING: ignoring dynamic library libc.wasm.so because not compiling to 
> JS or HTML, remember to link it when compiling to JS or HTML at the end
> error: undefined symbol: runTask
> warning: To disable errors for undefined symbols use `-s 
> ERROR_ON_UNDEFINED_SYMBOLS=0`
> Error: Aborting compilation due to previous errors
> shared:ERROR: 'H:/dev2/emsdk/node/8.9.1_64bit/bin/node.exe 
> H:\dev2\emsdk\emscripten\1.38.32\src\compiler.js 
> C:\Users\XXX\AppData\Local\Temp\tmp7btk6r.txt H:\dev2\emsdk
> \emscripten\1.38.32\src\library_pthread_stub.js' failed (1)
> ```
>
> How should I actually be generating dynamic modules?  Can I specify just the 
> base name to emcc?  like -o 'x.wasm' isn't really enough because it can 
> generate .js, .wast, .mem all at once....
>
> Do dynamic modules actually load each other?  Is all of that linking 
> information actually in the .JS file?  I did a quick search for the other 
> 'libraries' that core/image linked to... but didn't find that text...
>
> I have been able to take all of the following, and compact it into 1 module; 
> but in reality, the next projects cannot be conglomerated as easily....
>
> I have a structure kind of like... hmm
> several low level libraries like zlib, png, jpeg, freetype, genx, expat
> I have a common core module, which is definitely a good candidate for -s 
> MAIN_MODULE
> I have an image module, which links to core and zlib, png, jpeg, freetype
> I have a controls module, which links to core and expat, genx
>
> Then I have a loader.c (main.c)
>
> It does some things like setup emscripten filesystems, calls the core's 
> initialization, which should dynamically load the image module, which will 
> provide a structure with function pointers which the controls library will 
> use.
>
> It then runs a function in the controls module (the 'app')
>
> The layer, I have a presentation shell, which is a dynamic module, which 
> links to controls and core, but then it has a bunch of dynamic module 
> plugins, which link to core.
>
> These module plugins have no functions to export.  There was a comment I read 
> long the way saying 'a module that doesn't export anything is pretty 
> useless'.  Modules still have a start point, which allows them to run code 
> that lets them then register their functions/interfaces.  Function can also 
> just be flagged with `void f(void) __attribute__((constructor))` which will 
> cause them to run when the module loads, and doesn't require exporting 
> anything.
>
>
> --
> 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/6c61563e-6640-4316-ba18-4a2d99469bed%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-jcQz%3DNrtT5vN3YqzRC6WXcKkJC%2B-52H%3D4KOXc3H_aWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to