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.
> 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?
>> $uname -a
>> Darwin mini.example.com 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26
>> 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386
>>
>> Trying to install mysql 5 server, and get the entire MAMP thing going.
>> Install gets hung up on ncursesw and ncurses if I use +universal,
>> I did a little cleaning, and mysql5-server appears to be going now. I have
>> attached a tee'd log in case that helps.
>
> The log doesn't contain anything useful; all it says is the muniversal
> portgroup couldn't begin ncursesw's configure phase because the directory it
> tried to create already existed, probably because you tried before, it
> failed, and you tried again without cleaning. Clean ncursesw, then try
> installing ncursesw +universal again to get the real error message, then show
> us that.
I did that too. I finally just took off the +universal, which means I had to
clean again, but then things seemingly went along fine.
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!
Thanks for the pointers.
--
Scott * If you contact me off list replace talklists@ with scott@ *
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
