Hello,
I'll report on my experiences here a little bit. I'm running OS X 10.6.7,
and I've had no problems so far (I also go the MacPorts route). I typically
avoid the precompiled binaries based on my past experience with them. The
last time I tried to use them (when 4.5 was experimental), they *always* had
the latest experimental version that failed when building Amber due to some
unfixed bug. They also don't update as often as you can with MacPorts. I
realize people have reported that you can use the prebuilt binaries now, but
I feel like MacPorts is the more stable route, since you have a plethora of
compilers to choose from.
That said, I have numerous GCCs installed with MacPorts, all well-organized
by gcc_select:
Jason-Swailss-MacBook-Pro:test swails$ gcc_select -l
Available versions:
gcc40 gcc42 llvm-gcc42 mp-gcc43 mp-gcc44 mp-gcc45 mp-gcc46
40, and the two 42 versions are all Apple's editions of GCC less gfortran,
but 43-46 are all complete GCCs with g++,gfortran,gcc,gcj,etc (4.6 is the
latest, experimental version). I've tried building Amber with all 4
versions with equal success. They all perform equivalently, too, with the
default Amber optimization flags.
I've only ever had 1 problem building the compilers on Macs, and it gave
some error like this:
../../gcc-4.5.2/gcc/fortran/module.c:109:1: error: conflicting types
for 'pointer_t'
/usr/include/mach/vm_types.h:40:26: note: previous declaration of
'pointer_t' was here
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/./prev-gcc/xgcc
-B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/./prev-gcc/
-B/opt/local/x86_64-apple-darwin10/bin/
-B/opt/local/x86_64-apple-darwin10/bin/
-B/opt/local/x86_64-apple-darwin10/lib/ -isystem
/opt/local/x86_64-apple-darwin10/include -isystem
/opt/local/x86_64-apple-darwin10/sys-include -c -g -O2 -gtoggle
-DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -Ifortran
-I../../gcc-4.5.2/gcc -I../../gcc-4.5.2/gcc/fortran
-I../../gcc-4.5.2/gcc/../include
-I../../gcc-4.5.2/gcc/../libcpp/include -I/opt/local/include
-I/opt/local/include -I/opt/local/include
-I../../gcc-4.5.2/gcc/../libdecnumber
-I../../gcc-4.5.2/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc-4.5.2/gcc/fortran/options.c -o fortran/options.o
make[3]: *** [fortran/module.o] Error 1
make[3]: *** Waiting for unfinished jobs....
rm gfortran.pod gcc.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2
This is actually caused because I tried to outsmart some dated packages that
couldn't find malloc.h, and I created a symlink to malloc.h in /usr/include
from /usr/include/malloc/malloc.h, rather than just fixing the file to
include <stdlib.h> instead (which is what should be done now, as I
understand). Anyway, as long as users *don't* create this link, I think
they should be fine using MacPorts to build the compilers.
I would also suggest MacPorts over Fink, as fink will create gxx-4, forcing
users to sed -i -e "s.gcc.gcc-4.g" ... the configure file.
The MPIs, OTOH, I build myself and keep separated from one another (with
mpi-selector to manage them), which I've found to be quite an effective
system.
I also do frequent updates, and typically do a "port upgrade outdated" every
couple weeks, so I'm always running with the latest updates to every
package.
My 2c (although I wouldn't consider myself a Mac person any more than Dave
;) ).
All the best,
Jason
On Tue, Apr 19, 2011 at 1:03 PM, David A Case <case.biomaps.rutgers.edu>wrote:
> Hi everyone:
>
> I'm starting to see comments (so far, sent to me personally) about
> compiler/OS combinations that fail for MacOSX. I hadn't looked at
> http://amberonmac.blogspot.com/ for a while, but that looks like some good
> info. But I'd like to get developers' input on known "good" combinations
> for gnu compilers (no intel, pgi, etc for now please).
>
> For example, in spite of Mengjuei's bad-mouthing of mac ports, I've never
> had
> problems there. For me, with Mac OS 10.6.6, I use mac ports gcc44 (i.e.
> /opt/local/bin/gcc-mp-4.4) and corresponding gfortran. I've never seen
> any
> problems, and downloading/installing them was supersimple, so I'd be tended
> to
> recommend that path.
>
> Mengjuei indicates that the gcc+gfortran package at hpc.sf.net works for
> him
> (no OS revision is indicated). The amberonmac blog cited above has pretty
> complete details.
>
> What else seems to work? Is anyone running 10.6.7? I am still afraid to
> upgrade, although with all the virtual machines around these days it
> probably
> would not be that bad.
>
> Also, if anyone is still at 10.5 and has recommendations there, I'd
> appreciate
> it. (Again: for me I went with mac ports from the very beginning, and
> never
> saw the problems other people are seeing.)
>
> Also, if you have examples of specific error messages that arise when "bad"
> compilers are used, we might try to keep a registry of those somewhere, to
> help people out who run into them.
>
> Comments from "real" mac people are welcome.
>
> ...thx...dac
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Apr 19 2011 - 14:30:03 PDT
