On 9 July 2015 at 10:39, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> The use-case that I’d really like to go from mostly-working to actually-working is the ability to create symlinked versions of clang with a triple prefix and have it behave sensibly. We can symlink clang to mips64-unknown-freebsd-clang and get a working cross-compiler, more or less, except that we also want to specify things like the default sysroot. Having the bit in the name of the compiler just be a name for a config file containing a set of command-line options would be very nice - we’d have a set of predefined names, and then if someone wanted to provide a androidsdk-v47-arm.conf (or whatever) and just drop it into a known location then they’d be able to use androidsdk-v47-arm-clang as a cross compiler.This already works well with Clang, but is restricted to the triples that actually make sense. If you need to change anything that the triple can't, you're on your own. But I agree this is a sensible alternative, or even in conjunction, with CMake options or config files. cheers, --renato
On 9 Jul 2015, at 10:45, Renato Golin <renato.golin at linaro.org> wrote:> > On 9 July 2015 at 10:39, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: >> The use-case that I’d really like to go from mostly-working to actually-working is the ability to create symlinked versions of clang with a triple prefix and have it behave sensibly. We can symlink clang to mips64-unknown-freebsd-clang and get a working cross-compiler, more or less, except that we also want to specify things like the default sysroot. Having the bit in the name of the compiler just be a name for a config file containing a set of command-line options would be very nice - we’d have a set of predefined names, and then if someone wanted to provide a androidsdk-v47-arm.conf (or whatever) and just drop it into a known location then they’d be able to use androidsdk-v47-arm-clang as a cross compiler. > > This already works well with Clang, but is restricted to the triples > that actually make sense. If you need to change anything that the > triple can't, you're on your own.Right, the problem is that the triple almost never contains enough information for a cross-compile (which, at a minimum, needs to know where the default sysroot is, where to find cross-linkers, and may also need to target a specific CPU variant or turn on soft float). It works moderately well for trivial cases (e.g. targeting x86 Linux from x86-64 Linux, and even targeting ARM Linux from x86-64 Linux, as long as ARM Linux doesn’t mean Android or WebOS or some flavour of Linux that’s different from the host). I would really like to completely remove the triple as something that can be decomposed into meaningful components and just have it become a name, which is only used by the front end to identify a configuration. David
On 9 July 2015 at 11:02, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> Right, the problem is that the triple almost never contains enough information for a cross-compile (which, at a minimum, needs to know where the default sysroot is, where to find cross-linkers, and may also need to target a specific CPU variant or turn on soft float). It works moderately well for trivial cases (e.g. targeting x86 Linux from x86-64 Linux, and even targeting ARM Linux from x86-64 Linux, as long as ARM Linux doesn’t mean Android or WebOS or some flavour of Linux that’s different from the host).Yes, multi-arch / multi-lib kind of thing works well if we're only talking about Linux.> I would really like to completely remove the triple as something that can be decomposed into meaningful components and just have it become a name, which is only used by the front end to identify a configuration.That's what I'm sceptical about. I don't think that's possible. What we can (and should) do is to make it redundant. If we have a better solution, and it's clearly beneficial, people will start using it and maybe GNU tools could even implement that. Legacy systems will still use triples forever, though. cheers, --renato