Oh, sorry, I don't know why I thought Windows, the paths clearly show it isn't ;)
On Mac and Linux, I don't know of a general solution to this. It might require a change to llvm-opt, in order to accept the -internalize list as a path to a file. But another option might be to just disable internalize, which would avoid passing that list to llvm-opt. This would avoid all dead code elimination, though, but would work around this problem. Might be useful until that list is short enough. You can disable internalize with -s LINKABLE=1 On Tue, Jul 28, 2015 at 5:48 PM, Bailey Hayes <[email protected]> wrote: > 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]> 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]. >>> 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.
