[llvm-commits] PATCH: Add support for tracking and exposing the host triple

[Chandler Carruth]

On Tue, Jan 24, 2012 at 8:23 AM, Joerg Sonnenberger <joerg at britannica.bec.de
> wrote:

> I disagree with this. I don't the host OS is involved in any of the
> decisions. Let me summarize how NetBSD handles this case, I think the
> same applies to other platforms and can be moved into the upper layers.
>

Not really... I would look at the other platforms to understand why....


> When clang is invoked, it derives the base target either from program
> name, command line or configuration. During the NetBSD build, it is
> always the program name (e.g. x86_64--netbsd-clang). This base target is
> memorised and used for finding the tool chain, so that e.g.
> x86_64--netbsd-ld is used as linker. If the driver finds -m32 on the
> command line, three things change. The triple for the compiler invocation
> is changed to i386--netbsd. This changes the code generation only.
> Second, the library search path is changed from =/usr/lib to
> =/usr/lib/i386.
> That's where crt0.o and friends can be found. This differs from a
> "native" i386--netbsd compiler, since that expects the path correctly in
> =/usr/lib to match the native environment. Third, -m elf_i386 is passed
> to ld.
>

There are lots of other issues on non-netbsd systems such as where the GCC
toolchain is installed. For some Linux distros there is a nice predictable
location, but for others there isn't. For still others, there is a nice
predictable location, but it isn't as strictly related to the target as I
would like.


Anyways, see my response to James... this isn't enough even if I wanted it
to be, so I'm going to try a different approach anyways.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120124/84a82876/attachment.html>