On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote: > 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.
yeah, though using response files where supported, and libraries elsewhere is an option though somewhat complicated. > 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. I'm not sure grouping object files really makes things more modular, but if you could split some independent part of gcc into a reusable library that could be built as its own shared object that seems useful for both goals. Trev
