This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Avoid invoking ranlib on libbackend.a
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).
Segher