latest 64-bit command line build for Mac OSX 10.6.7?
Hi, I was trying to install the latest nightly build but get error (shown after my salutation) when using the recommended procedure: ./install --prefix=/Applications/ Previously, I always installed from source so I could run the 64-bit version on Mac since I have some structures that require as much memory as possible. Should I just go back to that? It does take about an hour to install on my laptop. I assume this latest 64-bit option would significantly reduce the time for installation since I wouldn't be compiling from the source. Cheers! Joe ========================================================================== PHENIX Installation version: dev release tag: 718 machine type: mac-intel-osx-x86_64 source machine type: mac-intel-osx OS version: osx-10.6.7 user shell: /bin/bash destination: /Applications/ ========================================================================= No binary bundles found for mac-intel-osx bundles directory contents: bundle-dev-718-mac-intel-osx-x86_64.tar.gz expected one of the following: /Users/sandiegonoels/Downloads/2011-04-03/phenix-installer-dev-718/bundles/bundle-dev-718-mac-intel-osx.tar.gz =============================== ERROR =================================== No binary installer found for mac-intel-osx, installation aborted =============================== ERROR =================================== ___________________________________________________________ Joseph P. Noel, Ph.D. Investigator, Howard Hughes Medical Institute Professor, The Jack H. Skirball Center for Chemical Biology and Proteomics The Salk Institute for Biological Studies 10010 North Torrey Pines Road La Jolla, CA 92037 USA Phone: (858) 453-4100 extension 1442 Cell: (858) 349-4700 Fax: (858) 597-0855 E-mail: [email protected] Web Site (Salk): http://www.salk.edu/faculty/noel.html Web Site (HHMI): http://hhmi.org/research/investigators/noel.html ___________________________________________________________
I have a guess, but I may be way off. It's probably because you are not running the 64-bit kernel? I think Macs still don't come running by default with a 64-bit kernel (except for a few high-end machines), but you can reboot your Mac with the 64-bit kernel. Now, why Phenix needs a 64-bit kernel to run as a 64-bit application, that's above my pay grade, and the developers would probably answer that. Engin On 4/3/11 10:57 AM, Joseph Noel wrote:
Hi,
I was trying to install the latest nightly build but get error (shown after my salutation) when using the recommended procedure:
./install --prefix=/Applications/
Previously, I always installed from source so I could run the 64-bit version on Mac since I have some structures that require as much memory as possible. Should I just go back to that? It does take about an hour to install on my laptop. I assume this latest 64-bit option would significantly reduce the time for installation since I wouldn't be compiling from the source.
Cheers!
Joe
========================================================================== PHENIX Installation
version: dev release tag: 718 machine type: mac-intel-osx-x86_64 source machine type: mac-intel-osx OS version: osx-10.6.7 user shell: /bin/bash destination: /Applications/ ========================================================================= No binary bundles found for mac-intel-osx bundles directory contents: bundle-dev-718-mac-intel-osx-x86_64.tar.gz expected one of the following: /Users/sandiegonoels/Downloads/2011-04-03/phenix-installer-dev-718/bundles/bundle-dev-718-mac-intel-osx.tar.gz
=============================== ERROR =================================== No binary installer found for mac-intel-osx, installation aborted =============================== ERROR =================================== ___________________________________________________________ Joseph P. Noel, Ph.D. Investigator, Howard Hughes Medical Institute Professor, The Jack H. Skirball Center for Chemical Biology and Proteomics The Salk Institute for Biological Studies 10010 North Torrey Pines Road La Jolla, CA 92037 USA
Phone: (858) 453-4100 extension 1442 Cell: (858) 349-4700 Fax: (858) 597-0855 E-mail: [email protected] mailto:[email protected]
Web Site (Salk): http://www.salk.edu/faculty/noel.html http://www.salk.edu/faculty/faculty_details.php?id=37 Web Site (HHMI): http://hhmi.org/research/investigators/noel.html ___________________________________________________________
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
-- Engin Özkan Post-doctoral Scholar Howard Hughes Medical Institute Dept of Molecular and Cellular Physiology 279 Campus Drive, Beckman Center B173 Stanford School of Medicine Stanford, CA 94305 ph: (650)-498-7111
On Sun, Apr 3, 2011 at 10:57 AM, Joseph Noel
I was trying to install the latest nightly build but get error (shown after my salutation) when using the recommended procedure: ./install --prefix=/Applications/ Previously, I always installed from source so I could run the 64-bit version on Mac since I have some structures that require as much memory as possible. Should I just go back to that? It does take about an hour to install on my laptop. I assume this latest 64-bit option would significantly reduce the time for installation since I wouldn't be compiling from the source.
There were several bugs in the install script - the convoluted workaround for using the 32-bit binary installer on Snow Leopard was causing problems for the 64-bit binary installer. I've patched the installer to fix the problem, and a new version is now posted online. It may have the side effect of breaking the forwards compatibility of the 32-bit build, but I will test and fix this tomorrow. (This is the first time the 64-bit build has actually run; Apple's habit of overengineering seemingly simple things like Unix user accounts made it surprisingly difficult to get our automation working.) -Nat (PS. the choice of kernel is irrelevant - 10.6 will always be detected as x86_64, and the 64-bit build should work with either kernel.)
On Sun, Apr 03, 2011 at 02:26:02PM -0700, Nathaniel Echols wrote:
(PS. the choice of kernel is irrelevant - 10.6 will always be detected as x86_64, and the 64-bit build should work with either kernel.)
Unless you are running on one of the very first Intel Macs using an Intel Core Duo CPU, which is 32-bit only. This is a minority population, but since people are reluctant to decomission Macs, we have already had several tickets on. e.g. 64-bit only CNS. -ben -- | Ben Eisenbraun | SBGrid Consortium | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |
On Sun, Apr 3, 2011 at 5:29 PM, Ben Eisenbraun
(PS. the choice of kernel is irrelevant - 10.6 will always be detected as x86_64, and the 64-bit build should work with either kernel.)
Unless you are running on one of the very first Intel Macs using an Intel Core Duo CPU, which is 32-bit only.
This is a minority population, but since people are reluctant to decomission Macs, we have already had several tickets on. e.g. 64-bit only CNS.
Oh dear. Well, they're definitely going to have problems with Phenix as it stands right now. Could you please check with one of these users and find out what the output of "uname -a" is? I believe there is a smarter way to identify 64-bit systems than what I'm doing now (basically, just looking at the OS version), but I need to make sure it won't result in false positives. A more general issue with 32-bit vs. 64-bit Mac (especially relevant to SBGrid): currently, if you install either the 32-bit (mac-intel-osx) or 64-bit (mac-intel-osx-x86_64) installer on Snow Leopard, the binary build directory will be $PHENIX/build/mac-intel-osx-x86_64. So they can't co-exist in the same location, which is potentially a problem for GUI users since wxPython 2.9 still has a few serious bugs, as well as some incompatibilities which we haven't dealt with yet. (There isn't anything that I'm aware of that is likely to cause crashes, but some features don't behave properly, such as anything using OpenGL.) I have no bright ideas for this, other than tracking down and fixing the problems; given the number of memory overflow errors I've been receiving lately in bug reports, the 64-bit builds are pretty essential. Further information here: https://www.phenix-online.org/platforms/mac_notes.html thanks, Nat
On Sun, Apr 03, 2011 at 05:45:49PM -0700, Nathaniel Echols wrote:
Oh dear. Well, they're definitely going to have problems with Phenix as it stands right now. Could you please check with one of these users and find out what the output of "uname -a" is?
It doesn't look particularly helpful to me, but here's a Core Duo iMac running 10.6.7: Darwin ps-common-imac.in.hwlab 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
I believe there is a smarter way to identify 64-bit systems than what I'm doing now (basically, just looking at the OS version), but I need to make sure it won't result in false positives.
I'm using `sysctl -n hw.optional.x86_64`, which will return 0 for non-64-bit capable hosts. -ben -- | Ben Eisenbraun | SBGrid Consortium | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |
On Sun, Apr 3, 2011 at 5:29 PM, Ben Eisenbraun
On Sun, Apr 03, 2011 at 02:26:02PM -0700, Nathaniel Echols wrote:
(PS. the choice of kernel is irrelevant - 10.6 will always be detected as x86_64, and the 64-bit build should work with either kernel.)
Unless you are running on one of the very first Intel Macs using an Intel Core Duo CPU, which is 32-bit only.
This is a minority population, but since people are reluctant to decomission Macs, we have already had several tickets on. e.g. 64-bit only CNS.
Okay, Engin reminded me why I originally wrote it to always treat Snow Leopard as 64-bit: if you have a 64-bit processor, the 64-bit build will work regardless of kernel type. However, if you are running a 32-bit kernel, the architecture will always be reported as "i386". So we're left with these choices: 1) Make the 'mac-intel-osx-x86_64' platform dependent on the 64-bit kernel, so everyone who needs the 64-bit build has to change kernel version or 2) Keep the current behavior, and people running Snow Leopard on first-generation Intel Macs will need to use the 32-bit binary installer. Neither is ideal; the latter has additional problems for SBGrid, due to the way we 'alias' the architecture when the 32-bit installer is used. Ben, did you decide what to do about CNS? -Nat
Hi Nat,
1) Make the 'mac-intel-osx-x86_64' platform dependent on the 64-bit kernel, so everyone who needs the 64-bit build has to change kernel version or 2) Keep the current behavior, and people running Snow Leopard on first-generation Intel Macs will need to use the 32-bit binary installer.
Neither is ideal; the latter has additional problems for SBGrid, due to the way we 'alias' the architecture when the 32-bit installer is used. Ben, did you decide what to do about CNS?
For the time being, we're just checking for 32-bit only CPUs and then forcing them to use an older version of CNS. I tried building a 32-bit CNS and lipo'ing the 32 and 64-bit binaries into a two-way fat binary, but the default CNS optimizations seem to cause the 32-bit version to blow up. This might also be due to me using the latest version of the Intel compiler. You should be able to use the hw.optional.x86_64 sysctl to tweak the phenix_env scripts to allow for a dual branch 32/64 bit installation in the same directory, but it seems like you're not yet recommending the 64-bit PHENIX on OS X Intel for general consumption. You could also do something hackish like default to 32-bit but read $1 on the "source phenix_env" command line to enable the 64-bit version. Between the wxPython issues and the fact that about 1/3rd of our OS X users are still on 10.5, unless I get a specific request for the 64-bit version, I probably will not install it just yet. (That's the cue for emails from the SBGrid users requesting a 64-bit installation... :-) -ben -- | Ben Eisenbraun | SBGrid Consortium | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |
On Mon, Apr 4, 2011 at 11:10 AM, Ben Eisenbraun
For the time being, we're just checking for 32-bit only CPUs and then forcing them to use an older version of CNS. I tried building a 32-bit CNS and lipo'ing the 32 and 64-bit binaries into a two-way fat binary, but the default CNS optimizations seem to cause the 32-bit version to blow up.
Unfortunately, this would be much more difficult with PHENIX, since it isn't a monolithic program like CNS.
You should be able to use the hw.optional.x86_64 sysctl to tweak the phenix_env scripts to allow for a dual branch 32/64 bit installation in the same directory, but it seems like you're not yet recommending the 64-bit PHENIX on OS X Intel for general consumption. You could also do something hackish like default to 32-bit but read $1 on the "source phenix_env" command line to enable the 64-bit version.
I think the sysctl command will at least let me distinguish between CPU types, so that takes care of the 64-bit detection problem. How to allow 32-bit and 64-bit versions to coexist is a separate issue; environment variables are another way, but neither of these options is intuitive. However, I think I figured out how to make them coexist in the same base directory, but only for the command-line installation; the graphical installers will still overlap. One clarification: for people who only use the command line, the 64-bit build is recommended - we haven't noticed any problems with program behavior so far and it will potentially save a lot of time and trouble to have access to all available memory. It's the GUI that's the problem, but I'm going to see if I can tackle that this week. -Nat
participants (4)
-
Ben Eisenbraun -
Engin Özkan -
Joseph Noel -
Nathaniel Echols