4 ms·
Blame the linker, not GCC. Also it's pretty well known that the order of command line arguments passed to the linker is important. It is sometimes also needed
by kccqzy 4y ago
Blame the linker, not GCC.
Also it's pretty well known that the order of command line arguments passed to the linker is important. It is sometimes also needed to pass a library to the linker multiple times.
- jepler 4y agoYes, sort-of, though the "imperative" linker flags -( and -) may help you. if you can figure out how to quote them properly (or use --start-group / --end-group)
- klysm 4y agoI did not know that but that does suck. The typical contract is that it shouldn’t matter beyond being able to parse it.
- cstrahan 4y agoI believe it would be that way, if not for performance. The linker keeps track of unresolved symbols, and resolves those symbols while parsing subsequent object files. So if you list a dependency before it is used, that dependency won’t be linked at all, resulting in unresolved symbols — thus the need for object files to be listed in a particular order. Edit: and the need for listing a dependency twice is to resolve mutually dependent object files. If A depends on symbols from B and B depends on symbols from A, you can link A,B,A or B,A,B (per the aforementioned reasoning).
- aslilac 4y agoWell known to people who are knowledgable in all the intricacies of the build tools used for systems programming, which I'm pretty sure is a much smaller group than you're assuming here.
- pandaman 4y agoAlso depends on the linker. This is the behavior of bfd/gold, usually the default linker on Linux but lld allows "back references" as it targets more platforms and many of those don't care about the ancient UNIX convention.