Ah interesting! That sounds like a much less hacky way of doing things, and I'll give it a shot! Thank you!
On Mon, Nov 7, 2016 at 5:40 PM, Alon Zakai <[email protected]> wrote: > Sorry, there isn't a supported way to do that. The closest is llvm-extract > but it does the opposite (leaves only the stuff you want, instead of > removing it). With not too much work we could add a pass to emscripten to > remove functions, but that would be after dce though. > > Adding libcxx variants worries me about complexity. Overall, I'd guess the > best alternative to that is to just grab the string headers and code from > libc++ and hack on them at the source level to get exactly what you want, > then build with that. The system libc++ won't be linked in in that case > (it's only linked in when symbols are unresolved that it provides). > > On Mon, Nov 7, 2016 at 4:07 PM, 'Ben Vanik' via emscripten-discuss < > [email protected]> wrote: > >> Thanks for the response! >> >> Hmm yeah, without changes to libc++ it sounds tricky... :( >> >> Is there a way to blacklist or replace symbols during linking in >> emscripten? I can of course hack things, but using a supported hack would >> be nice if it existed :) >> >> I ask because I've been fiddling and by just commenting out the contents >> of ios_base::Init (https://github.com/kripken/em >> scripten/blob/master/system/lib/libcxx/iostream.cpp#L38) that sets up >> cin/cout/etc (that I never use) my closure-optimized/gzipped binary went >> from 308K to 237K (!). If I could - at link time - substitute that function >> (and a few others) it may be enough to get down to a reasonable size. >> >> The other way I see would be to change system_libs.py to add >> a create_libcxx variant that excludes some of this via preprocessor defines >> (similar to how DISABLE_EXCEPTION_CATCHING works). Would a DISABLE_STDIO be >> an interesting PR? >> >> On Mon, Nov 7, 2016 at 1:51 PM, Alon Zakai <[email protected]> wrote: >> >>> Yeah, any c++ standard library feature can lead to a large increase in >>> code size, as it ends up linking in big parts of libc++. >>> >>> Optimally, it would be nice if upstream libc++ were refactored to avoid >>> that, but I have no idea how feasible that would be both technically and >>> not. >>> >>> Alternatively, you can use your own custom String class instead of >>> std::string. You can then make sure it doesn't handle locales and the other >>> complexity that causes big parts of libc++ to get lumped in. >>> >>> Otherwise, some compiler opts might help. On a hello world using an >>> std::string and -Os, I see 91K output (similar to you). With --closure 1 I >>> see 72K (at the cost of a slower build time) and with --closure 2 I see 66K >>> (at the cost of both slower build time and slower runtime as it disables >>> asm.js). >>> >>> Longer-term, wasm will help here. I see the compiled code in that format >>> is 30K (however, we currently disable minifying the JS part, which we need >>> to fix). >>> >>> >>> On Mon, Nov 7, 2016 at 1:18 PM, 'Ben Vanik' via emscripten-discuss < >>> [email protected]> wrote: >>> >>>> My resulting asmjs outputs are massive and it's making me sad! I've >>>> tracked most of the size down to ios_base's global initializer (and the >>>> world that it pulls in) -- even though I'm not using iostream (or really >>>> much of anything) and was wondering if anyone had a way to get around this. >>>> >>>> My hello world sample compiles to 6KiB, but if I include <string> and >>>> add a single `std::string foo;` it jumps up ~100KiB (even in -O2 with >>>> --llvm-lto 1). >>>> The big difference in output comes down to this: >>>> ``` >>>> function __GLOBAL__I_000101() { >>>> var label = 0, sp = 0; >>>> sp = STACKTOP; >>>> __ZNSt3__18ios_base4InitC2Ev(0); >>>> return; >>>> } >>>> + a billion functions called by ios_base::Init. >>>> ``` >>>> >>>> That ios_base::Init pulls in locale and a bunch of other stuff that is >>>> only ever called from that stack. Because it's a global initializer >>>> dead-code removal won't get rid of it and it ends up in my final output. It >>>> seems a bit silly that even when not using iostream >>>> (cin/cout/strstream/etc) I still take a massive hit. >>>> >>>> I found this issue from a year or so ago which seems like exactly what >>>> I'm seeing: >>>> https://github.com/kripken/emscripten/issues/2545 >>>> >>>> Unfortunately the fix proposed never made it in: >>>> https://github.com/kripken/emscripten/pull/3308 >>>> >>>> Besides not using std::string anywhere (which is extremely difficult >>>> given the code I'm compiling) has anyone found solutions for removing this >>>> bloat? Is there any emscripten features (in-progress or planned) that will >>>> help situations like this? >>>> >>>> -- >>>> 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/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]. >>> 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]. >> 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
