ccc-gcc-name equivalent to call as and ld directly

Hi,

There is ccc-gcc-name clang parameter which allows specifying custom gcc to be used for assembling and linking. This is quite useful when cross-compiling for different architecture.

Problem is that this works only when 2 2-part triple is specified (i.e. -ccc-host-triple arm-elf ). In my case i need to cross-compile for different OS so I need to specify something like -ccc-host-triple arm-unknown-freebsd (compiling on Mac OSX) and in this case gcc is not invoked. Clang calls default AS and LD directly and that of-course fails.

I wonder about possibility to introduce similar cmd line parameters (i.e. -ccc-gas-name and -ccc-ld-name ) to specify cross-assembler and cross-linker directly.

This will also avoid need for having gcc in toolchain.

Any thoughts?

Thanks,

Damjan

Hi Damjan,

I'm not sure, but I believe that if you call clang as
"arm-none-freebsd-clang" (via symlink), it'll set the target triple
automatically and should default to looking for "arm-none-freebsd-as"
and so on.

If it doesn't do that yet, it should. James might know more about it,
as he was fiddling with that recently.

Regarding the parameters, I don't object having them. It makes it
easier to build automated tests where you want to change the
assemblers and linkers at will.

cheers,
--renato

Hi,

This comes back to the same as a previous conversation:
http://article.gmane.org/gmane.comp.compilers.clang.devel/15299

Reliance on GCC to point the way to the correct assembler and linker makes
sense for Linux because of its heavily GCC-centric view of the world, but
seems more of a hindrance for cross-compilation development, both baremetal
and cross-OS.

I believe that Renato is incorrect in the behaviour he noted - Clang sets
the host triple based on the exec prefix, and will pull out the OS part so
use the FreeBSD Toolchain class instead of the GCC-oriented "Unknown" class.

Not only this but the default behaviour in not just the FreeBSD toolchain
but any other is to look for the bare tool name "as"/"ld" instead of first
trying a triple-prefixed version ("arm-none-freebsd-as").

Cheers,

James

I strongly suggest you look at the cross-compiling changes I did for
NetBSD. Essentially, it is looking for ${TARGET}-as and ${TARGET}-ld
first.

Joerg

Hi James, Renato,

At least on Darwin this trick with symlink doesn't work. clang still tries to run /usr/bin/as.

My understanding is that currently only clang on NetBSD host is taking into account -ccc-host-triple to construct command line to invoke AS and LD. I submit a patch[1] to implement the same on FreeBSD and
Darwin, but this bug is still in NEW state after 2 months. With this patch cross-compiling works fine for me.

However I think that it will be nice to have possibility to specify custom AS and LD from command line and avoid messing with symlinks. If there is common agreement that this should be implemented, I can write a patch. However I don't want to spend time if there is no interest to include it into SVN.

Cheers,

Damjan

[1] http://llvm.org/bugs/show_bug.cgi?id=9777

Yes, I submitted patch to implement the same on Darwin and FreeBSD based on your code,
however it is after 2 months still in NEW state. I would like to know
if there is anything else I can do to help getting this into SVN.

Thanks,

[1] http://llvm.org/bugs/show_bug.cgi?id=9777

Please, send the patch to cfe-commits, so it can be properly reviewed.

cheers,
--renato

OK, done.

What about adding command line parameters to specify assembler and linker?
Do we agree that this is something we would like to have implemented?

Hi,

I'd be happy with that. I've also wanted the ability to bake in as and ld locations "GCC-style" at configure time for a while.

If it's not too much extra work, would you mind at all adding your patch (to look for $(TARGET)-as/ld directly) to the Unknown toolchain also?

So that in effect it would check $(TARGET)-as/ld and fallback to GCC as it does currently. Even better, fall back to $(TARGET)-gcc first?

I understand this is slightly beyond the initial scope of your patch, but it would really help baremetal cross-compilation targets.

James