divide and conquer method for linker

Question

I have multiple files (>300 object files), whose need in linking with "ld" command. Now, I waste a lot of time, while I wait linking process will be done (and this process not always will be successful).

I have next question: can I use "divide and conquer" method for linking, e.g. link every pair object files (for example objfile1.o and objfile2.o) in single object file (for example objfile1-2.o). After it apply this scheme for every pair of objects. Further, link every pair objects, that were got on previous stage, and so on. Finally, link a few objects (may be pair) in one result file.

Can I use this scheme for linking (with ld)?

Answer 1

The binary splitting is probably not a good idea, but you likely can improve link times by breaking the application up into several shared objects, and linking against those. When linking against a shared object, the linker doesn't have to actually copy the data into the executable, but only check that the shared object does define the needed symbols.

Still, 300 object files is not a lot, and shouldn't slow things down that much, ad least with a modern system, at least if they're on a local drive. (Back in the old days, when everything was on a remote drive, we used to set up our makefiles so that the link phase would run on the file server, rather than on our local machine. This could speed things up by a factor of 10 or more.)

Answer 2

No matter how you approach it, when linking the final executable, the linker has to peruse the whole list of contents. Any intermediate "staging" of the linking process will only increase the runtime.

Picture it:

• object1.o contains foo(), bar()
• object2.o contains fiddle(), lee()
• main.o contains main(), which calls the above functions

When you're linking, the linker will need to link the functions together, regardless of whether they are in one file or two files.

Answer 3

No, that's not a suggested way. However, you may create static or shared library for portions and link with the shared library for multiple executables, if any linked with the shared library. That will surely take some time less than monolithic linking for every executable without any overlap.