Apart from being unhappy about the performance, it's been a very unstable/shacky start for me (June 2003) to get it all working. Overall, the installation of NEMO now works, but I always seem to need some tinkering, which appears to depend on the OS patch level.... My new system (baught June 2004!) fared a little better, no doubt 10.3 is better than 10.2 (and I've also been spoiled too much with Solaris and Linux....). Don't even get me started on this inferior Aqua. By now i feel Gnome has surpassed it in capabilities. At least out of the box, i'll say that. There are tons of tools to make Aqua more useful, but take out your credit card and/or be ready to babysit some downloading, installation and disk "optimizing"!
/usr/lib/crt1.o definition of _NXArgc in section (__DATA,__data) /usr/lib/crt1.o definition of _NXArgc in section (__DATA,__data)this seems to depend on the version of autoconf, 2.57 is ok, 2.59 - which comes with mac - does not
[this was done with gcc-3.3 (build 1809) on os-x 10.4.5
where the default compiler was actually 4.0.0 (build 4061) -
but this version cannot compile gyrfalcON]
% cd $NEMO/usr/dehnen/falcON
% edit Makefile
-shared => -flat_namespace -bundle -undefined suppress
(see also $NEMOBIN/ldso; not sure if we can even use shared libs
since their official extension is .dylib, not .so)
% edit make/defs
-rdynamic : remove it, this flag is not needed on mac
-rpath : remove it, this flag cannot be used on mac
(or: make sure you use STATIC compile only)
-lg2c => -lgfortran : but only if you wind up using gcc4
% make -i CXX=g++-3.3 nemo_bins
some executables might fail to compile... but gyrfalcON works
And performance? Well, nothing is for free. So far i get just a tad (10-20%) lower performance on a G4 vs. a P4 (at the same clock speed, given that most P4's run about 2-3 faster than a G4, well... to me that's a no brainer). If you normalize that by the price, we're 4-6 times off. If you have money, and energy to reprogram your code for altivec, or use dual processors, yes, go and make my day. But i still feel that the P4's are beating the G4's. G5? Come on, they only give you about 10-20% improvement at the same clock speed....
PS: yes. i'm a tad over-reacting. I spent just way too much money on this, and finding working software (despite fink) isn't as easy as i had hoped. gosh, it makes living with rpm's look easy now!
PSPS: I'm also keeping some links on darwin as i'm learning more about this, as well as my miriad/MacOSX notes which sometimes remind me of tricks of the Mac trade. Many thanks to Gaurav Khanna, Mark Bellon and Nicolas Martin for their patience in guiding me through this new forest.
1. Download: (use tar or cvs, make sure you get the CVS/pgplot version, not the one via Caltech, it doesn't have the darwin config files) cvs -Q co nemo cd nemo (mkdir local; cd local; cvs -Q co pgplot) 2. Configure the system. Some G5 systems may have the IBM compiler, which can confuse configure. Setting these 3 environment variables will set them more reliably for the gnu compiler: setenv CC gcc setenv F77 g77 setenv CXX g++ ./configure --with-yapp=pgplot --with-pgplot-prefix=`pwd`/lib Check the output, notably if X11 was detected properly for pgplot. Also, consider running autoconf yourself to overwrite the configure script, but it currently breaks more things than it fixes. 3. Important: For MacOSX you now need to edit makedefs and NEMORC.gen (or NEMORC.local if it was already there) and rid them of any references to -lcrt1.o -lcrt2.o and/or -lcrtbegin.o in the FLIBS and YAPPLIB variable resp. (which ones you see seem to depend on the compiler version and/or phase of the moon): emacs NEMORC.gen makedefs Oddly enough one persons 10.3 is not another persons... My own phase of the moon was clean, i had to change nothing!! 4. Set the NEMO environment for user and programmer source nemo_start make postconfig source NEMORC.local Note that NEMORC.local is a copy of NEMORC.gen, so on MacOSX make sure there are no references to the .o files mentioned in item 3. If you edited NEMORC.gen the step before, you're ok. 5. Compile the pgplot library (inside $NEMOLIB) - there may be some fatal errors with complaints about undefined symbols like restFP and saveFP, but those won't have an impact on NEMO. make pgplot 6. Compile the NEMO library, it will silently do this and log the results in install.log make libs rehash 7. Now compile two sample routines to check if a simple and a more complex (graphics) program compile ok: mknemo tsf mknemo tabhist 8. If this is ok, continue to install the testsuite, if not, probably need to tinker with NEMORC.local (source it again) and/or $NEMOLIB/makedefs: src/scripts/testsuite -b There will be a few small errors still, to be resolved. 9. For MacOSX users who have an unpatched HFS+ filesystem, there could be a few duplicate files that were mapped on top of each other (the filecase bug), you'll have to figure this out yourself. I believe as of April 2004 NEMO is now clean of such duplicates.