On Monday, April 7, 2014 4:20:01 PM UTC-7, Ben Vanik wrote: > > --rescan-libs is awesome Ryan. You mention a possible perf issue in the > comment; have you experienced this or is it speculative? I'd vote to have > something like this enabled by default if it didn't mean 2x longer builds. > I've been bit by this ordering issue a few times and it's painful to work > around. >
Well, I just included that warning because the --start-group/--end-group docs do and the algorithm is worst case O(archives^2). In practice it will be very little overhead. It's just a bunch of extra dictionary intersections in python. You could theoretically construct a case where you were building with thousands of archives with a linear dependency chain between them, each of which had thousands of symbols, and you passed those to emcc in the exact wrong order (from dependency to dependants), then it would do a lot of extra work (but probably STILL not expensive compared to the actual llvm calls...). In the case I was testing with there are dozens of large archives in an order that requires 4 complete passes and the additional passes took around 1ms extra. If anyone ever hit a bad case where this slowed them down it could be improved at the cost of memory. How much memory depends on how slavishly you want to adhere to the link order (vs just making it work with any symbol when there are dups). Ryan > > On Mon, Apr 7, 2014 at 2:07 PM, Ryan Sturgell > <[email protected]<javascript:> > > wrote: > >> I have a patch at >> https://github.com/rsturgell/emscripten/tree/rescan_libs which adds a >> --rescan-libs flag to emcc which behaves as if -Wl,--start-group and >> -Wl,--end-group surround all the inputs. >> >> I have to say, though, I hate to add another way to do specify this... I >> think it would be better to just properly support groups, but this will be >> more complex. We'd have to either handle the flags in emcc and maybe pass >> some kind of tree through to the link function, or propagate -Wl,* linker >> flags through and handle the grouping in link. But both of these interact >> poorly with the processing that happens to these inputs in emcc. It will be >> a big change to make it all work. >> >> Another option which doesn't add complexity is go with --rescan-libs but >> default to true (!). This way emcc will just work with whatever archive >> order. This is exactly how msvc does it (from >> http://msdn.microsoft.com/en-us/library/hcce369f.aspx): >> >> Object files on the command line are processed in the order they appear >> on the command line. Libraries are searched in command line order as well, >> with the following caveat: Symbols that are unresolved when bringing in an >> object file from a library are searched for in that library first, and then >> the following libraries from the command line and /DEFAULTLIB (Specify >> Default Library) <http://msdn.microsoft.com/en-us/library/229a6ysd.aspx> >> directives, >> and then to any libraries at the beginning of the command line. >> >> >> Thoughts? >> >> Thanks, >> Ryan >> >> >> On Tuesday, April 1, 2014 6:48:28 AM UTC-7, Warren Seine wrote: >>> >>> This is something I need and it suits my requirements. At the moment, >>> I'm using the wonderful solution of adding libraries twice in the command >>> line (which works btw...), so anything cleaner is better. >>> >>> On Tuesday, April 1, 2014 5:27:24 AM UTC+2, Alon Zakai wrote: >>>> >>>> From the perspective of maintainability both sound reasonable, the >>>> latter sounds much simpler though, so if that is good enough for the >>>> people >>>> that want this functionality then it is preferable. >>>> >>>> - Alon >>>> >>>> >>>> >>>> On Fri, Mar 28, 2014 at 2:24 PM, Ryan Sturgell <[email protected]>wrote: >>>> >>>>> Hi all, I'm also interested in --start-group/--end-group. I'm trying >>>>> to build an existing project which uses gyp and ninja to build, and gyp >>>>> basically passes the .a files in an arbitrary order and wraps the whole >>>>> set >>>>> in --start-group/--end-group. >>>>> >>>>> Supporting this functionality in shared.Building.link should be >>>>> possible (passing a list of archive-groups instead of a list of >>>>> archives). >>>>> >>>>> Alternatively, the particular case of gyp could be handled by >>>>> supporting a new emcc-specific flag like --group-all or something which >>>>> specifies that the whole set of archives should be repeatedly scanned as >>>>> if >>>>> they were all contained in --start-group/--end-group. This would be >>>>> simpler >>>>> to implement. >>>>> >>>>> Do either of these options sound palatable? I could take a stab and >>>>> putting a patch together. >>>>> >>>>> Thanks, >>>>> Ryan >>>>> >>>>> >>>>> On Thursday, March 6, 2014 3:18:27 PM UTC-8, Alon Zakai wrote: >>>>> >>>>>> Hmm yes, .a files do work that way I believe, and we support linking >>>>>> them with proper semantics, so that should work. >>>>>> >>>>>> - Alon >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 6, 2014 at 12:26 AM, Warren Seine <[email protected]>wrote: >>>>>> >>>>>>> Thank you. I've had a look at the llvm-link source code, and there >>>>>>> used to be an option --start-group which was simply ignored (and >>>>>>> has since been withdrawn), so I'm wondering if that's the default >>>>>>> behaviour >>>>>>> now. >>>>>>> >>>>>>> Anyway, somebody mentioned that I could put together all the .a >>>>>>> files into a single one and then only link the big one. I guess that'd >>>>>>> work? I'll try that. >>>>>>> >>>>>>> >>>>>>> On Wednesday, March 5, 2014 10:56:42 PM UTC+1, Alon Zakai wrote: >>>>>>> >>>>>>>> The most relevant doc is likely https://github.com/kripken/ems >>>>>>>> cripten/wiki/Building-Projects but you can just look in emcc to >>>>>>>> see what we support and do not support. I've never heard of that >>>>>>>> option, so >>>>>>>> I guess we don't support it. >>>>>>>> >>>>>>>> - Alon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 5, 2014 at 12:50 AM, Warren Seine >>>>>>>> <[email protected]>wrote: >>>>>>>> >>>>>>>>> @Alon, any idea? Can you describe (or point me to a page >>>>>>>>> explaining) the linking step? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday, March 4, 2014 9:21:09 AM UTC+1, Warren Seine wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> -Wl,--start-group and -Wl,--end-group are compiler options to >>>>>>>>>> tell the linker to look for symbols in previous libraries, as in >>>>>>>>>> "before in >>>>>>>>>> the command line". They seem to have no effect on link order with >>>>>>>>>> emcc and I'm not really surprised because the link step is >>>>>>>>>> different from native builds in many ways. I'm wondering if someone >>>>>>>>>> has >>>>>>>>>> been there and found a workaround to avoid unresolved symbols when >>>>>>>>>> linking >>>>>>>>>> static libraries with circular dependencies. >>>>>>>>>> >>>>>>>>>> I can reorder manually reorder libraries or put them twice, but >>>>>>>>>> for some reason I'd prefer to use this feature (or something >>>>>>>>>> similar) which >>>>>>>>>> works fine with gcc. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>> >>>> -- >> 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.
