On Fri, 22 Jun 2018, Steve Ellcey wrote: > I can see both sides of this and don't feel strongly one way or the > other. I have attached a new patch that does allow for the use of just > -l options to force the linker to be called.
I don't think this patch achieves the desired semantics. My understanding of the desired semantics is: just as doing plain gcc or gcc -O2 produces an error gcc: fatal error: no input files compilation terminated. so the same should apply if a linker option is passed, e.g. gcc -Wl,-rpath,/some/where (rather than the present attempt to link) but if a -l argument is passed, that should be treated as an input file and the driver should continue to try to link just as it does at present. And then, for the case you were concerned with, building precompiled headers, all three commands, with the name of a header to compile to a PCH file added to them, should again act the same: compile the header to a PCH file, do not try to link. But actually, what I see with the patch applied does not follow that. If I do ./gcc/xgcc -B./gcc/ -lm it does *not* try to link, just exits silently. And if I do ./gcc/xgcc -B./gcc/ -Wl,-nosuchoption it does *not* complain about a lack of input files, but again just exits silently. However, if I do ./gcc/xgcc -B./gcc/ -Wl,-rpath,/some/where it *does* try to link, when by the expected semantics, it should complain about the lack of input files. It appears that it's caring about whether the -Wl, arguments start with '-' or not, which is completely wrong - /some/where above is an argument to the -rpath linker option, it's not an input file. (For the next patch revision also note the "linnked" typo in a comment.) -- Joseph S. Myers jos...@codesourcery.com
