<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/1/2 Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div><br><div><div>On Dec 30, 2012, at 1:42 , Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div><br><blockquote type="cite">

On Sat, Dec 29, 2012 at 11:27 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:<br><blockquote type="cite"><br>On Dec 29, 2012, at 13:54 , Anton Korobeynikov <<a href="mailto:anton@korobeynikov.info" target="_blank">anton@korobeynikov.info</a>> wrote:<br>

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

asking for cross-build.<br></blockquote><br>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".)<br>

</blockquote><br>I find this surprising -- this configuration *doesn't* look like it's<br>building a cross-compiler to me, since target=host. What's the<br>justification for a prefix here? Why would leaving target empty<br>

("target matches host") give a different prefix from explicitly<br>setting target to match host?<br><br>I'm not saying this is wrong (and the "don't set a target" advice<br>seems good to me), but I don't think the explanation so far justifies<br>

our behavior.<br></blockquote><br></div></div></div><div>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 <i>do</i> want a prefix.</div>

</div></blockquote><div><br></div><div>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.<br>

FYI, this is not what GCC's autoconf does.<br><br></div><div>That being said, omitting --target works around this bug.<br><br></div><div>Thanks,<br></div><div><br></div><div>Ruben<br></div><div> </div></div><br></div>
</div>