This is an intended use case, that sounds like a bug. Any chance you can make a testcase showing it?
Fastcomp is likely a better way to improve your iteration time though, as it is much more heavily tested than the static linking feature (at least currently). But please make a testcase if you can, that's how we can make static linking more stable. - Alon On Mon, Feb 10, 2014 at 11:30 PM, Dave Nicponski <[email protected]>wrote: > Hello all, > > Sorry for the terse email, but it's 2:30am here and i'm about to give up > for the night. > I have a project roughly as follows: > > The project contains currently a main method and a set of worker code, > intended to be run in web workers in browsers, or via the webworker-threads > module in nodejs. > > Each of these requires a rather large support library (statically > compiled, rarely changing) to work. It contains things like the protocol > buffer libraries, for instance. > > The support libraries have been precompiled into llvm bitcode. Most of > the development iteration is done on the main and worker modules. As such, > compilation time after modifying either of those is very important to me. > > To minimize this, here's what I had in mind. > 1) compile the static library bitcode into a javascript MAIN library. > > iterate one of: > > 2a) Modify and compile main() module into a SIDE library > 2b) run "emlink.py static.js, main.js main_out.js" > > or > > 3a) Modify and compile worker module into a SIDE library with > BUILD_AS_WORKER=1 option > 3b) run "emlink.py static.js worker.js worker_out.js" > > Sadly, step 3a reliably fails since worker.js doesn't have a memory > initialization section! This causes tools/asm_module.py to fail trying to > spot memory_initializer_patter, when in fact only > no_memory_initilizer_pattern is present in that file (worker.js). > > Is this know / meant to be an unsupported use case? Is there an easy > workaround? > Tomorrow i'll try using fastcomp (which i suspect would eventually work), > but for tonight i don't have the energy. > > I'll supply additional info tomorrow if requested. > > Thanks, > -dave- > > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
