4 ms·
Most linkers support archive "groups" at the command line, so you don't need to do the topological sort. Most linkers also support relocatable objects, so you c
by saurik 6y ago
Most linkers support archive "groups" at the command line, so you don't need to do the topological sort. Most linkers also support relocatable objects, so you can trivially solve the symbol collision problem by just linking together a subset of your app and then stripping that symbol before linking the conflict. And like, it frankly just sounds like you have never heard of libtool, which adds most of the stuff in your edit--like dependencies and configurable linker settings--to the static link process, and which has not only existed but has been widely used among most marquee projects for over two decades. :/
- cryptonector 6y agoI know all about libtool, thank you, and I'm quite aware that it writes dependency information into its .la files. I use libstool every day. It sucks. This functionality has to be built into the linker.
- saurik 6y agoMaking the linker--which is architecture specific and generally "just barely what is required to munge together object files"--into some fat stack of code (that I guess you would expect to work the same for every single linker) because you don't believe wrappers are appropriate for some reason is a disagreement over "clean reusable architecture" and not that the ecosystem as a whole is somehow "stuck in the 80s" :/.
- cryptonector 6y agoPart of what has to be done can be done in wrappers, it's true: the part that has to do with recording additional metadata. But the other part -using that metadata to resolve symbol conflicts- cannot be done in a wrapper -- it has to be done in the linker-editor. IMO this is a very strong argument for putting all of this in the linker-editor.