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/ > emscripten/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.
