Re: Always use -c -o when compiling C

[Peter Rosin]

On 2013-05-30 00:39, Stefano Lattarini wrote:
> On 05/30/2013 12:14 AM, Peter Rosin wrote:
>> Hi!
>>
>> I just tried the testsuite on maint with MSYS/MSVC and I have one
>> failure, namely in silent-many-languages.sh. The reason it fails is
>> that while I have specified MSVC as the C and C++ compiler, I didn't
>> bother to say that I wasn't interested in fortran. The many-lang
>> test then mixes the output from the GCC fortran compiler with the
>> output from MSVC, which is perhaps not very wise but appears to work
>> for the trivial code in the testcase once you fix the automake
>> machinery to allow it.
>>
>> The problem with the automake machinery in this case is that GCC
>> uses foo.o, while MSVC uses foo.obj, and it so happens that GCC
>> "wins" and OBJEXT is set to "o". This, coupled with the fact that
>> automake tries not to use the -o option unless it's really needed
>> causes make rules to be created w/o -o, but MSVC will then create
>> foo.obj, which fails badly during linking when automake expects
>> foo.$OBJEXT, i.e. foo.o.
>>
>> So, since the maint branch already assumes that -c -o works, how
>> about the below change? It makes the test PASS for me, and I see
>> no regression in any other test (but I have a lot of SKIPs, so
>> I'm not really confident that the change will not cause some
>> spurious FAILs in any of those).
>>
>> The concept seems sound to me, but it's perhaps too dangerous?
>>
>> Cheers,
>> Peter
>>
>> diff --git a/bin/automake.in b/bin/automake.in
>> index 24ff2a6..40b3181 100644
>> --- a/bin/automake.in
>> +++ b/bin/automake.in
>> @@ -632,6 +632,7 @@ register_language ('name' => 'c',
>>                    'linker' => 'LINK',
>>                    'link' => '$(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) 
>> $(LDF
>>                    'compile_flag' => '-c',
>> +                  'output_flag' => '-o',
>>                    'libtool_tag' => 'CC',
>>                    'extensions' => ['.c']);
>>
>> @@ -1313,14 +1314,6 @@ sub handle_languages ()
>>         if (((! option 'no-dependencies') && $lang->autodep ne 'no')
>>             || defined $lang->compile)
>>         {
>> -           # Some C compilers don't support -c -o.  Use it only if really
>> -           # needed.
>> -           my $output_flag = $lang->output_flag || '';
>> -           $output_flag = '-o'
>> -             if (! $output_flag
>> -                 && $lang->name eq 'c'
>> -                 && option 'subdir-objects');
>> -
>>             # Compute a possible derived extension.
>>             # This is not used by depend2.am.
>>             my $der_ext = ($lang->output_extensions->($ext))[0];
>> @@ -1364,7 +1357,7 @@ sub handle_languages ()
>>
>>                              COMPILE   => '$(' . $lang->compiler . ')',
>>                              LTCOMPILE => '$(LT' . $lang->compiler . ')',
>> -                            -o        => $output_flag,
>> +                            -o        => $lang->output_flag,
>>                              SUBDIROBJ => !! option 'subdir-objects');
>>         }
>>
>>
> I think we already have something similar in master, in fact.  Not sure
> why I didn't apply that directly to maint, since all the changes necessary
> for such a simplification are in maint as well.  Perhaps because I did
> this simplification in a middle of another master-based patch series, so
> that it didn't apply cleanly to maint?  Probably so.
> 
> In short, I agree this change goes in the right direction.  Thank you.
> Extra kudos if you can prepare a patch with the complete explanation,
> and maybe even a reference to the similar change already landed in
> master.  I will give a fresh round of tests on Fedora, Debian, BSD
> and Solaris tomorrow.

I'm not sure we should even hint at any support mixing MSVC and GCC,
which would be implied if we did this change in order to fix the
testsuite failure. I believe this change needs to stand by itself,
because the testsuite failure is not an important case, it was just
how I got to look at the code and what drove the .o vs .obj
confusion, that's all. That said, I suppose I can mention it with
a fair warning that nobody recommends mixing toolchains.

The commit you're referring to is 020fb48db730a5 "subdir-objects:
enable unconditionally", right?

(I'm on master now, so I'll write up a suggestion for the commit
message later, when I'm done with bug#14499 and bug#14501)

Cheers,
Peter