On Sun, 17 Jul 2016, David Edelsohn wrote: > On Sun, Jul 17, 2016 at 10:43 AM, Patrick Palka <patr...@parcs.ath.cx> wrote: > > On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn <dje....@gmail.com> wrote: > >>>>>>> Patrick Palka writes: > >> > >>> Hmm, this is only a problem due to command line length limits right? > >>> Fortunately the change makes the longest command line only about 10% > >>> longer than the previous longest command line. With the change to > >>> avoid building libbackend.a altogether, the longest command line is > >>> now the cc1plus link command which is 4430 bytes long. Without this > >>> change, the longest command line is the "ar rc libbackend.a" > >>> invocation at 4095 bytes (from what I can tell). It's still pretty > >>> far away from the 8k limit imposed by Windows. > >> > >> Windows is not the only non-Linux system on which GCC runs. > >> > >> You repeatedly are making bad assumptions and assertions without > >> having studied much about GCC. You assume that GNU ar is the only > >> archiver in use. You propose removing libbackend.a without having > >> investigated when it was introduced and why. > >> > >> Your patches would be a lot more compelling if you invested the time > >> to learn some context. > > > > The only patch I officially proposed is the one elides the invocation > > of ranlib if the current ar is GNU ar (thanks to those who kindly > > mentioned that other ar's are supported). Do you have any comments > > about this patch? > > Testing for and utilizing a feature of GNU ar that speeds up builds > seems like a nice improvement, but it obviously adds complexity and > increases the risk that an independent change silently will introduce > build problems on some systems. > > > And you're right. I am sorry for suggesting ways to improve rebuild > > times without first uncovering the undocumented intricacies of the > > build system. Shame on me! > > Yes, GCC is a large and intricate Free Software project. And > contributing patches requires some archaeology to understand the > motivation and reason for the design choices as part of the software > engineering process. GCC supports and runs on a very large and > diverse set of systems, which is one facet of its strength. > > One goal of GCC is evolution toward a more modular design: > > https://gcc.gnu.org/wiki/ModularGCC > > Thanks, David >
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. It's probably not safe to remove this archive even today since it currently stands for about 5000 bytes of object file names. Simply removing it and having the build system refer to $(OBJS) will likely make us exceed 8k bytes in a command line somewhere. 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.
