New install MAMP

[Scott Haneda]

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@ *