This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] pass @-files to collect2 and beyond


Dave Korn wrote:

>> I don't think that's likely to be necessary.  Binutils has supported
>> response files for quite some time now.  And, most people get GCC and
>> Binutils as part of a single distribution.  And, if you're building your
>> own GCC, you can probably build your own Binutils to go with it.  In any
>> case, we can come back and address that later -- with appropriate
>> configury goo -- if necessary.
> 
>   Solaris toolchains still frequently mix gcc with native as/ld, don't they?  Shouldn't this depend on whether or not we had --with-gnu-ld (or autodetected it) at configure time?

Yes, that's a good point.  (I tend to forget that: I don't use Solaris
much, and CodeSourcery's toolchains use GNU binutils on Solaris.)

However, the problem here is that people tend to use response files when
command lines are too long for the system.  So, not using them for
subprocesses will often result in a silent error; the OS will truncate
the command-line and something odd will happen.

Nathan, if I understand correctly, the change to gcc.c is only for
invoking ld?  That makes sense, as the command-line for "as" is unlikely
to be very long.

In that case, I think we need to arrange as follows:

1. Modify gcc/configure.ac to define HAVE_GNU_LD if the user specified
--with-gnu-ld.

2. Modify your patch to make the response file substitution only if
HAVE_GNU_LD (in both the driver and in collect2).

As a minor nit about the patch:

+static int at_file_supplied;		/* Whether to use @file arguments */

it's considered better to use "bool" within GCC for boolean variables.
(Underneath, this is a typedef, but it's more intuitive for readers.)

Also, the duplicated code between collect2.c and gcc.c is troubling.  I
think that we should provide another function in libiberty/argv.c, like:

int
writeargv(const char **argv, FILE *file)

which writes ARGV to FILE, handling all quoting, and returns zero on
success.  That's a natural inverse to buildargv, already in that file.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]