How do I determine the fastest link order?

Question

I have about 50 different static libraries being linked into my c++ project and the linking takes on average 70s.

I\'ve found that moving around with the link order of

Answer 1

You're speaking of a one-pass ordering based on order of objects and libraries, but if it's searching through a static library it can't guarantee anything in the static library will be in any particular order and in fact you can only control that by ordering the static library a certain way when you ar it.

Furthermore, without understanding how the linker makes use of the static librar(y|ies), the two best assumptions that could be made is:

1. It creates a hash table of symbols that references the object(s) that provide or need them; if this is an accurate assumption, then the best lower bound you can get on a static library is the time it takes to populate such a hash table and read from it.
2. It blindly reads from the archive based on the order given in the archive's index.

As an attempt to find a lower bound on your optimal link time, try linking all or a subset of the the objects in the archive(s) as a relocatable object; for the subset, if possible identify all the objects actually linked in.

The man page for lorder indicates you can get the same results with ar ts ... which will print the ordered list for you. The man page for ar seems to indicate running ar with the s flag will automatically store that optimal ordering in the archive's index.

Also, be aware there could potentially be cyclic dependencies, though if you've already messed with tsort you should've been made aware of that already.

Finally, I'll leave you with one last piece of information. What you want is something that can solve an NP-complete problem. Good luck.

---

I've been running some timing tests the last little while for a build I work on; I've add the s flag to my ARFLAGS to see what effect it has.

Overall, it seems to have increased my build time but I believe there's a logical explanation for why:

• Most of the executables/shared objects do not use static linking
• It's building PIC and non-PIC versions of each static library

If we were making much heavier use of static libraries we'd probably see a benefit from doing this.