On Monday, April 7, 2014 4:37:12 PM UTC-7, Alon Zakai wrote: > > Very interesting about msvc. However different behavior from gcc/clang > sounds worrying. But, if there is no perf downside (as Ben just asked) and > no compatibility issues, might be worth considering. >
The compatibility issue would be that builds that fail with "symbol not found" in gcc/clang might succeed in emcc. Well... there is one real case that could be a problem. If you implement a function which overrides something from a library_*.js (like, say, glCreateShader), for example: emcc main.o lib1.a lib2.a Where: main.o does NOT call glCreateShader lib1.a contains obj1.o, which implements glCreateShader (and nothing that main.o depends on, so is not included on the first pass) lib2.a contains obj2.o, which uses glCreateShader and implements a function that main calls (so that it IS picked up on the first pass) With the current implementation, obj1.o is not included in the link, and glCreateShader ends up binding to the implementation in library_gl.js (however that works). But with --rescan-libs, obj1.o would be picked up on the second scan, and the implementation there would be used. > If we do handle groups, we would need to do it in emcc and the linking > code in tools/shared. > Right, that's where I made the changes for --rescan-libs in my branch. > We do linking ourselves except for calling llvm-link which is very > low-level and does not support groups and such, last I checked. > Correct. llvm-ld DID handle --start-group/--end-group but llvm-ld was dropped in llvm 3.2 because it was incomplete and clang is where all that logic happens now. > Hopefully it wouldn't be too complex, but I don't know offhand. > As I mentioned above it's not _too_ bad (the changes in tools/shared.py would be very similar to what I have in my branch), the hard part is plumbing it all together since the grouping needs to propagate through from emcc to shared.py. I guess the cleanest way would be to unwrap -Wl,--X options to --X in the option parsing in emcc, keep these around in the file list, make sure to pass them through all the transformations / filters that happen in there, and pass those through to shared.building.link. Ryan > - Alon > > > > 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.
