This is the mail archive of the
mailing list for the GCC project.
Re: [Patch] Do not call the linker if we are creating precompiled header files
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Steve Ellcey <sellcey at cavium dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 9 Aug 2018 22:34:03 +0000
- Subject: Re: [Patch] Do not call the linker if we are creating precompiled header files
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
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
produces an error
gcc: fatal error: no input files
so the same should apply if a linker option is passed, e.g.
(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
./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
(For the next patch revision also note the "linnked" typo in a comment.)
Joseph S. Myers