Yes, sounds like the right direction, a pull request would be great, thanks.
I am a little confused by the `ORIGINAL_EXPORTED_FUNCTIONS` part, but maybe it'll make sense to me in the pull. On Fri, Aug 14, 2015 at 10:42 AM, Bailey Hayes <[email protected]> wrote: > 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]> 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. > -- 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.
