On Jun 5, 2010, at 23:15, Scott Haneda wrote: > On Jun 5, 2010, at 7:07 PM, Ryan Schmidt wrote: > >> On Jun 5, 2010, at 20:00, Scott Haneda wrote: >> >>> Mac Mini that seems to be 64 bit capable... >>> $file `which ls` >>> /bin/ls: Mach-O universal binary with 2 architectures >>> /bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64 >>> /bin/ls (for architecture i386): Mach-O executable i386 >> >> All that tells us is that your "ls" command contains x86_64 and i386 >> executables, which AFAIK will always be the case on Snow Leopard, regardless >> what processor you have. To see whether your Mac is actually 64-bit capable, >> run: > > Bah, ok, I thought that if a UB existed, that the CPU had to support it. So > the OS knows how to ignore the bits of a binary that have architecture > specific builds in it even if the hardware itself can't support it? Thats > interesting to learn. So in theory, you could see `file` return PPC as an > option, even if it were obviously as in this case, Intel? > > I never would have thought this to be the case, and thought it more like > trying to run a classic app on a new machine of today.
Sure. That's the point of universal binaries: they contain many architectures, and the OS uses the best one for the Mac it's currently running on. >> sysctl hw.cpu64bit_capable >> >> If it says "1" your Mac is 64-bit capable; if it says "0", it isn't. (The >> first Intel-based line of Mac minis used Intel Core processors (which are >> not 64-bit capable)). > > That is the command I wanted then, and that explains it: > $sysctl hw.cpu64bit_capable > hw.cpu64bit_capable: 0 > > What is getting me, is this should be 64 capable, according to > system_profiler: > > Hardware Overview: > Model Name: Mac mini > Model Identifier: Macmini1,1 > Processor Name: Intel Core Duo > Processor Speed: 1.66 GHz > Number Of Processors: 1 > Total Number Of Cores: 2 > L2 Cache: 2 MB > Memory: 2 GB > Bus Speed: 667 MHz > Boot ROM Version: MM11.0055.B08 > > I thought only the Core Solo's were not 64 bit capable, and anything Core 2 > Duo were? Or is this the difference in a Core Duo and a Core _2_ Duo? That's exactly the difference. The Intel Core Solo and Duo are 32-bit processors (with 1 or 2 cores, respectively), while the Intel Core 2 Solo and Duo are 64-bit processors. > Someone on #macports said this was a bug, which is why I came here. I am > guessing this is not a bug, and I was doing this wrong, which was trying to > build universal on a arch that does not support it. > > Hoever, would it not be a good idea to save the user from this mistake? If > hw.cpu64bit_capable returns 0, then either the +universal could be ignored, > which could be ambiguous to the user, with them thinking a UB was made, or, > MP could exit out with an error: "Sorry, your machine does not support > building as +universal". > > I managed to get it all running, another MAMP install successfully working, > hooray! Again, the machine *does* support the notion of universal binaries; all Macs running 10.4 or later do. It may not, however, necessarily support compiling, for example in your case, 64-bit software on a 32-bit machine. You could set universal_archs to "ppc i386" (instead of the Snow Leopard default of "x86_64 i386") and it should be able to do that. Not that there's any reason to do that, but it would prove to you that you can build a universal binary for *some* set of architectures. But as you said, even for ports that do build 64-bit on 32-bit machines, there's probably no reason why someone with a 32-bit machine should want to do so, so it might not be unreasonable for MacPorts to exit with a helpful error if trying to build for a 64-bit architecture on a 32-bit machine (i.e. either universal_archs contains x86_64 or ppc64 and the universal variant is used, or build_arch is x86_64 or ppc64 and the universal variant is not used). Could you file a ticket for this request? _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
