I noticed that there is another setting, ORIGINAL_EXPORTED_FUNCTIONS, that is also being passed to llvm-opt. I made a change to keep ORIGINAL_EXPORTED_FUNCTIONS as the original response file which helped me get past the 'too many Arguments' exception for the smaller executable.
I also found that internalize-public-api can take a file as an argument. I modified shared.py to write out the finalized exports list to a file and then pass that file to llvm. The last trick to get things working was to convert EXPORTED_FUNCTIONS back to a response file before calling emscripten.py and then also expanding the response file in emscripten.py. If those changes sound on track to you, I can open a pull request. On Wednesday, July 29, 2015 at 2:37:08 PM UTC-4, Alon Zakai wrote: > > 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] > <javascript:>> 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.
