jakehehrlich added a comment. I'm not misunderstanding, please seem my post on llvm-dev where I layout the different issues involved. You're underestimating the complexities involved here I think. Trivializing what the linker does to "the linker just merges these" is a gross oversimplification that doesn't account for symbol consuming vs exporting, size, alignment, visibility, linkage, symbol type, symbol versioning (which is impossible to handle here without consuming version scripts as was pointed out by someone else), which symbols are untimely exported/consumed or even intermediate operations on .o files via tools like objcopy (which is uncommon and shouldn't be a hard blocker here but something to think about). Also all linkers behave just a bit differently with respect to these issues so 1) the reality is that the thing that merges these will behave just a bit differently than any existing linker but 2) even if it trys to match one linker it will fail to match the other so it will only be compaitable in all cases with atmost one linker (but probably none when edge cases are considered. I also already pointed out the issue with having to search all source files on the tree. I agree that if you were to use the linker to accomplish this that would would have to look at all source files. Further more many flags passed to the linker untimely affect these things making matters more complicated. The "linker" you describe for these cases is far from "cat".
For reference when I say "module" in this context I mean the output of the linker. "DSO" is synonymous. A DSO/module can be an executable or shared object but we can consider both here. I was not referring to C++ modules. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60974/new/ https://reviews.llvm.org/D60974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
