automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Always use -c -o when compiling C


From: Stefano Lattarini
Subject: Re: Always use -c -o when compiling C
Date: Thu, 30 May 2013 10:34:32 +0200

On 05/30/2013 08:20 AM, Peter Rosin wrote:
> 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?
>
Actually no, it was one if its follow-ups.  Let me dig for it ...
Here: v1.13.1d-217-g7299c4d "depend: assume we can always pass '-o'
to the C compiler".

> (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)
>
OK, thanks.

Regards,
  Stefano




reply via email to

[Prev in Thread] Current Thread [Next in Thread]