RE: An unreviewed patch for the gcc driver

["Dave Korn" <dave dot korn at artimi dot com>]

On 30 May 2007 20:15, Mark Mitchell wrote:

> Dave Korn wrote:
> 
>>>   gcc -c hello.c -Wl,blah
>>>   fido-none-elf-gcc: blah: linker input file unused because linking not
>>> done 
>>> 
>>> Notice that we get this warning even though we are not specifying any
>>> object file to be fed to the linker.
> 
> The specific case that led Kazu to this patch is:
> 
>   gcc -c hello.c -Wl,--hash-style=both
> 
> Here, the user is clearly not trying to pass a file to the linker;
> instead, the user is trying to pass an option to the linker.  So, for
> starters, the error message doesn't make sense in this case; it should
> say something like "linker option ignored because linking not done".

  Ah, I see that.  I was thrown by the fact that 'blah' is very clearly not an
option but a file name... I didn't realise it was a metasyntactic blah!

>>> We
>>> determine whether infiles[i].name is a linker option or not by looking
>>> at whether infiles[i].language is "*".
>> 
>>   Is it really the case that infiles[].language is set to a "*" if
>> something is a linker option?
> 
> I didn't write the patch, or review it until now, but I believe Kazu is
> correct.  The driver appears to set the language field to "*" for the
> <arg>s in only the following cases:
> 
>   -Wl <arg>[,<arg>,...]
>   -Xlinker <arg>
>   -l <arg>
>   -l<arg>
> 
> The driver sets the "language" field for unknown files (including ".a"
> files) to SPEC_LANG, which is either NULL, or the value specified with
> the "-x" option -- but never "*".  "*" is reserved for options.
> 
> The "-l" case is not as clear-cut as the option case above.  When the
> user says "-lfoo" that's rather similar to saying "libfoo.a", so one
> could argue they should be treated identically.  However, in practice,
> people are much more likely to put "-lsocket" into LDFLAGS than
> "libsocket.a".
> 
> So, with Kazu's patch, the driver will issue the warning only when the
> user passes a ".o", ".a", ".lib", etc. file -- but not when passing a
> linker option.  I think this is a good pragmatic choice.
> 
> Do you still object to the change?

  Nope, I don't.  I /think/ it will do the wrong thing in the corner case of
passing an object file with no '.o' extension directly to the linker by using
-Wl,<filename> but passing an object file behind the driver's back like that
is not something we want to support or encourage anyway.  (I can't think of
any special use for it, and the documentation clearly describe -Wl et.al as
passing an /option/ to the linker, so although it generally works in the
straightforward way you would expect, a mildly off warning doesn't bother me).
Omitting the warning in the -l case seems totally reasonable to me.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....