--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.
On Mon, Apr 7, 2014 at 2:07 PM, Ryan Sturgell <[email protected]>wrote: > I have a patch at > https://github.com/rsturgell/emscripten/tree/rescan_libswhich 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]. > 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.
