[cfe-dev] Passing -r to the linker

[Daniel Dunbar]

> Hi,
>
> Is there a good reason why -r is not passed to the linker?  There is a
> line for it in Options.def, but it is not marked as "l" so the linker
> doesn't see it and things break when you try using it.  If this is an
> oversight, I shall correct it, otherwise please let me know what the
> correct fix is.

Note that marking it with "l" is not the correct fix. Think of
Options.def as defining the AST for command lines, thats (hopefully)
target independent. On the other hand, what actually happens to the
"-r" is up to the tool chain and its tools.
"l" is a special flag which changes the driver action more than just
passing the option to the linker. Specifically, its the difference
between:
--
ddunbar at giles:tmp$ clang -r
clang: error: no input files
ddunbar at giles:tmp$ clang -Wl,foo
ld: file not found: foo
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--

It's true that we do encoding some logic about how arguments get
forwarded in Options.def, but this is conceptually an expedient hack.

On Wed, Sep 2, 2009 at 5:46 PM, Mike Stump<mrs at apple.com> wrote:
> On Sep 2, 2009, at 4:05 PM, David Chisnall wrote:
>> Is there a good reason why -r is not passed to the linker?
>
> It passes it for me:
>
> $ touch t.c
> $ clang t.c
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.6.o
> ld: symbol(s) not found
> $ clang t.c  -r -nostdlib -o me
>
> ConstructJob has:
>
>   Args.AddAllArgs(CmdArgs, options::OPT_r);
>
> which is how it works for me.  You can add this line to yours...  That
> is simple and easy.  Now, as for what's best... I suspect sharing more
> bits between architectures would be good.  This certainly seems like
> one to share.

Right. The non-Darwin ld Tool implementations are incomplete I suspect.

The way I envisioned this working is that the people who care about
their respective platforms would implement the full tool definition,
and we would refactory things (along with target hooks) as
appropriate. Unfortunately no one has undertaken this for Linux or
FreeBSD, so perhaps I should write a specs -> clang Driver C++
converter. :)

 - Daniel