On Mon, Jul 18, 2016 at 1:35 PM, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote: >> I did some digging to figure out the origin of libbackend.a. It was was >> created to work around a command line length limit on a VAX system >> (https://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00438.html). The 1600 byte >> command line that links cc1plus was too large for this system, so >> libbackend.a was introduced and used in place of $(OBJS) to reduce the >> size of this command line. > > As Zack said in that thread, at the top of the mail you refer to here: > "Putting the back end in a library seems like a good idea to me, never > mind whether or not we're really hitting command line length limits." > > Many people agree with that. Some, anyway. > >> I suppose rebuild times could instead be further reduced by splitting >> libbackend.a into multiple logical archives. It would also be a small >> step towards making GCC more modular. > > Is it faster to not have one big archive? There are nine compilers. > > If you want to add -s to the ar flags (it is POSIX, most systems should > have it by now), you should add a configure check (or find one, there is > bound to be one somewhere already) to test for it, and then add it to > AR_FLAGS (and there is also AR_CREATE_FOR_TARGET, it may be useful to > add it there as well -- needs a separate test of course). > > Or, if using GNU ar, you can even use -S, if that helps (after testing > for it in configure, of course).
While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is when you get rid of the archive or save link time by creating a (partially) linked DSO. ISTR Michael Matz has patches to do that. Whether it's portable enough is another question (I suppose it simply uses libtool). Richard. > > Segher
