Clang is prefixed by triplet?

Hi,

I built the 3.2 release as usual on a x86_64 linux build machine with host=target=i686-w64-mingw32, and I ended up with triplet-prefixed binaries. This is unexpected to say the least, and certainly not a documented change. Same goes for x86_64-w64-mingw32. It is usual for a native compiler to not be prefixed.

This is a bug. How can I fix this (i.e. end up with normal “clang.exe” without renaming everything after the fact)?

Thanks,

Ruben

PS: please keep me in CC, I am not subscribed to cfe-dev

This is a bug. How can I fix this (i.e. end up with normal "clang.exe"
without renaming everything after the fact)?

No, this is normal, since build != host / target and you're definitely
asking for cross-build.

This is a bug. How can I fix this (i.e. end up with normal "clang.exe"
without renaming everything after the fact)?

No, this is normal, since build != host / target and you're definitely
asking for cross-build.

Right. We went through a few iterations of this with the Hexagon guys, who are actually using prefixes. In your case, the best thing to do is leave 'target' empty if you want unprefixed executables; this means "target matches host" and AFAIK matches GCC's behavior. (At least, it's what our autoconf does. Before 3.2, we had program prefixes completely disabled, so you couldn't even set one manually. Now you can set one manually, but you also get the default behavior of prefixing for "configurations that look like cross-compilers".)

Since Clang doesn't actually need different binaries for different targets, there shouldn't be any reason to set 'target' anyway.

This is unexpected to say the least, and certainly not a documented change.

Since we aren't really using "target" the way GCC does, I'm not sure what the "expected" behavior is, but the documentation is a good point. cfe-dev, should this be recorded somewhere?

Jordan

>> This is a bug. How can I fix this (i.e. end up with normal "clang.exe"
>> without renaming everything after the fact)?
> No, this is normal, since build != host / target and you're definitely
> asking for cross-build.

Right. We went through a few iterations of this with the Hexagon guys, who
are actually using prefixes. In your case, the best thing to do is leave
'target' empty if you want unprefixed executables; this means "target
matches host" and AFAIK matches GCC's behavior. (At least, it's what our
autoconf does. Before 3.2, we had program prefixes completely disabled, so
you couldn't even set one manually. Now you can set one manually, but you
also get the default behavior of prefixing for "configurations that look
like cross-compilers".)

Since Clang doesn't actually need different binaries for different
targets, there shouldn't be any reason to set 'target' anyway.

OK, I'll see what this gives me. Thanks for the suggestion.

Ruben

I find this surprising -- this configuration *doesn't* look like it's
building a cross-compiler to me, since target=host. What's the
justification for a prefix here? Why would leaving target empty
("target matches host") give a different prefix from explicitly
setting target to match host?

I'm not saying this is wrong (and the "don't set a target" advice
seems good to me), but I don't think the explanation so far justifies
our behavior.

We were a bit surprised too, but that’s what autoconf does. I think the justification is that if you special-case target=host, there’s no way to get a target-prefixed compiler on the current host if you do want a prefix.

You could specify exec-prefix which prefixes every executable. The current
situation is stupid. A cross-compiled (build != host) native toolchain
(host==target) is now not the same as one you build in exactly the same way
natively (build==host). Nor is a CMake build the same as a configure build.
FYI, this is not what GCC's autoconf does.

That being said, omitting --target works around this bug.

Thanks,

Ruben