Thanks for the fast response! The static analysis can definitely be improved. For a first pass, it exports all of the symbols of a given class if it's found and all of the symbols of inherited classes. Another issue that complicates things is that it's also a component library so all of the public API's of a given namespace are exported. This puts the exported function count at around ~7,500. For the application use case, I can definitely whittle this down more, but not in the scenario of building this as a library or component. Ideally the wrapper source code can stay the same for building as a library vs app, so I would still want to pass in a large number of functions when building as a library.
I'm hitting this error on OSX. On Tuesday, July 28, 2015 at 7:09:34 PM UTC-4, Alon Zakai wrote: > > emcc at that stage emits something like > > opt -strip-debug -internalize > -internalize-public-api-list=main,malloc,free,__errno_location,fflush > -globaldce -pnacl-abi-simplify-preopt -pnacl-abi-simplify-postopt > -enable-emscripten-cxx-exceptions -disable-loop-vectorization > -disable-slp-vectorization -vectorize-loops=false -vectorize-slp=false > -vectorize-slp-aggressive=false > > where the "-internalize" list is generated from EXPORTED_FUNCTIONS. I > guess on windows that might hit a limitation if the list is long enough. > I'm not sure if LLVM opt has a way around that, but maybe there is a > general windows solution for this kind of thing? > > Another question, though, why is the EXPORTED_FUNCTIONS list so long? It > should only contain the methods that you will call from outside JS (not > from other compiled code), which should be a known list - I guess I'm > confused by why static analysis would be needed? > > On Tue, Jul 28, 2015 at 3:46 PM, Bailey Hayes <[email protected] > <javascript:>> wrote: > >> I'm building a large project that is the combination of several >> libraries. Currently, I'm exporting every public API in all of the included >> libraries by adding the C attribute "used" in my wrapper API, e.g. "int >> __attribute__((used, noinline)) getFoo()". >> >> I want to reduce the size of the final output by statically analyzing the >> API's that are actually being used by my application and pass them in as >> EXPORTED_FUNCTIONS. I hoped that by passing a file reference, I could still >> include a large number of functions to export. Any suggestions for where to >> go from here? >> >> Traceback (most recent call last): >> >> File "/emsdk_portable/emscripten/master/emcc", line 1260, in <module> >> >> shared.Building.llvm_opt(final, link_opts) >> >> File "/emsdk_portable/emscripten/master/tools/shared.py", line 1428, in >> llvm_opt >> >> output = Popen([LLVM_OPT, filename] + opts + ['-o', target], >> stdout=PIPE).communicate()[0] >> >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", >> >> line 709, in __init__ >> >> errread, errwrite) >> >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", >> >> line 1326, in _execute_child >> >> raise child_exception >> >> OSError: [Errno 7] Argument list too long >> >> -- >> 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] <javascript:>. >> 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.
