site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Mon, Aug 31, 2009 at 13:33, Andrew Gallatin<gallatin@cs.duke.edu> wrote:

Mo McRoberts wrote:

...

therefore break. In contrast, most other x86_64 systems tend to be set up such that x86_64 is reported as the “system” architecture (where the kernel architecture is pretty incidental), and so you have a triplet of, say, x86_64-pc-linux-gnu.

Where most is linux?  Nobody can really even agree if its amd64 or x86_64, much less what uname is supposed to say. For example, here's FreeBSD/amd64:

% uname -a FreeBSD thor 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196400: Thu Aug 20 09:38:12 EDT 2009     gallatin@thor:/usr/src/sys/amd64/compile/THOR  amd64 % uname -p amd64

Once you translate amd64 to x86_64, it behaves the way you'd expect. gcc defaults to producing 64-bit binaries.

Replace “FreeBSD” with “the BSDs [excepting Darwin]” Indeed; you _can_ conclusively translate amd64 to x86_64. You can't do the same for i386, because it’s ambiguous. As you say, OpenSolaris is similarly irritating, though it produces binaries by default matching the detected architecture so it’s not a problem in practice. If either of (a) the developer tools on Mac OS X produced i386 binaries by default (which wouldn’t affect Xcode, as it always explicitly specifies) or (b) something was output (by uname, arch, whatever) which told semi-recent versions of config.guess that the default arch was x86_64 and not i386, the problem would go away as far as I can see. M. -- http://nevali.net _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com