A PS on the Intel compiler / Xcode issue: the first work-around (-use-asm) does not work in conjunction with OpenMP enabled. Thus, I recommend to revert to Xcode 3.2.1 (and then reinstall the compilers) until the issue has been fixed by Intel.
Axel On Jun 9, 2010, at 5:19 PM, Patel, Pryank wrote: > > Hi all, > Thanks to everybody who has contributed over the past couple of days on the > various bulletin boards I have posted to. As is always the case, the solution > was quite simple but completely passed me by. I'm going to use Mac > inexperience as an excuse here... :-) > > So the original problem was not being able to compile a working executable of > CNS v1.21 from source on Mac OSX 10.6.3. The reason for compiling from source > is because in order to run CNS from Aria 2.3, a program used in NMR automated > peak assignment and structure calculation, CNS needs to be recompiled with > Aria-specific source code. With fink-installed gfortran/gcc 4.5 compilers, > CNS compiles and links with no warnings or errors, but fails at the execution > stage. With fink-installed 4.4, CNS compiles successfully but when executed > produces a simple "segmentation fault" message. > > The problem here is the fink-installed compilers. Harry Powell and Daniel > O'Donovan have guided me to the light - the High Performance Computing for > Mac OS X webpage (http://hpc.sourceforge.net) has binaries for the gcc 4.5 > compiler package, which installs in /usr/local/. Compilation with this > compiler set produces a working CNS executable. The only other modification > is to copy the Makefile.header.2.gfortran file from > cns_solve_1.21/instlib/machine/supported/intel-x86_64bit-linux to > cns_solve_1.21/instlib/machine/supported/intel-x86_64bit-linux. Compile with > 'make install compiler=gfortran', making sure that /usr/local/path is in > $PATH. > > With the Intel 11.1 compilers (and I used the evaluation version here), CNS > compiles successfully, but fails on execution. Thanks to Axel Brunger and > Benjamin Bardiaux, for sharing that the Intel fortran compiler is not > compatible with Xcode 3.2.2, although it does not seem to break gfortran in > this case. A little more information can be found here: > > http://software.intel.com/en-us/articles/intel-fortran-for-mac-os-x-incompatible-with-xcode-322/ > > Thanks goes to Benjamin Bardiaux for the link. The webpage suggests two > fixes. One is to add the '-use-asm' option to both the compilation and linker > lines. This seems to work, and produces a working CNS executable. Not until > now did I consider Xcode to be the problem, and at no point over the past few > days did I come across or register the intel webpage linked above during my > hours of google-trawling. > > The other option is to reinstall Xcode 3.2.1, which I assume is the version > Axel Brunger said he reinstalled. This can be downloaded from the Mac > Development Centre. Then reinstall the Intel fortran compiler. I have not > tried this option, since the first option seems to have worked quite well. > > Thanks once again, > Pryank > > > > On 9 Jun 2010, at 19:54, Axel Brunger wrote: > >> Please note that the latest version of Xcode in Mac OS X 10.6.3 >> breaks the Intel Fortran and C compilers. It is possible that Xcode also >> breaks gfortran, but I haven't tested it. I've reverted to the >> Xcode version that came with the original Snow Leopard release. >> >> Intel is aware of the problem, but so far there have been no >> updates of the Intel compilers to fix the problem with Xcode. >> >> Axel Brunger >> >> On Jun 9, 2010, at 11:35 AM, Ethan Merritt wrote: >> >>> On Wednesday 09 June 2010 10:45:07 am James Holton wrote: >>>> I have often wondered how it is that one can actually run and play games >>>> like Pac-Man(R) on a modern PC using the actual bit-for-bit contents of >>>> the EPROM cartridges that I used to put into my Atari 2600 (circa 1982), >>>> but for some reason programs written just a few years ago will neither >>>> compile nor run on the "latest and greatest" linux/gcc systems. >>> >>> I seriously doubt that your Atari PacMan program was written in Fortran! >>> But more to the point, to run it now you run an emulator for the original >>> Atari chipset. PacMac runs around thinking he really is on an Atari >>> console, >>> blissfully unaware that the console is only an emulated simulation of the >>> original long-gone world. Welcome to the matrix. >>> >>>> Am I missing something? >>> >>> I think you are missing the mark twice in mentioning "linux/gcc". >>> >>> The complaint under discussion is with OSX, not a linux system. >>> With rare exceptions, old linux programs run just fine on an up-to-date >>> linux system, so long as you also install equally old versions of the >>> support libraries. Do you have a counter-example in mind? >>> >>> In the specific case of old Fortran programs, the reality is that in the >>> era of commercial Fortran compilers there was great divergence in the >>> details of the implementation, particular with regard to I/O commands. >>> gcc/f77/g77 was never a good Fortran compiler, and was particularly bad at >>> compiling code idioms used by "real-world" Fortran code written for >>> compilers supported by IBM, DEC, CDC, etc. gfortran is somewhat better, >>> but still far from perfect. >>> >>> >>> As to Pryank's problem: >>> >>>> Pryank Patel wrote: >>>>> >>>>> Hi all, >>>>> I've posted this in the hope that somebody in the CCP4 community may >>>>> have come across this problem and can shed some light. I've posted >>>>> this question on other lists (cnsbb, ccpnmr and aria - the reason will >>>>> become clear), but with no success so far. >>>>> >>>>> I have recently acquired a Macbook Pro running OSX 10.6.3, (Kernel >>>>> version 10.3.0) and am unable to compile cns v1.21 from source, using >>>>> either the gcc 4.2.1/4.4/4.5 compilers (4.4 and 4.5 installed using >>>>> fink), and the Intel 11.1 (evaluation) compilers. >>> >>> I may be mis-remembering, but I have it in mind that the cns source code >>> requires selecting or porting a set of compiler-specific routines in one >>> of the source modules. These are work-arounds for the variability in >>> Fortran implementations mentioned above. Did you tweak this file >>> appropriately for each of the compilers you tried? >>> >>> As a practical matter, you might want to look into running a VMWare layer >>> on your machine so that you can compile and run linux executables rather >>> than fighting the native OSX environment. You too can join PacMac in >>> the happy world recreated in the matrix :-) >>> >>> Ethan >>> >>> >>> >>>>> I am aware that >>>>> there are Mac OSX binaries available, but I am also using CNS for NMR >>>>> structure calculation with the Aria 2.3 program, and to run that >>>>> successfully CNS needs to be re-compiled with Aria-specific source code. >>>>> >>>>> With the gcc4.5 compilers, CNS compiles and links with no warnings or >>>>> errors, but fails at the execution stage. When I try to execute cns, >>>>> either with './cns' or by running one of the test scripts, I get the >>>>> following: >>>>> dmemory error code = ****** >>>>> %ALLHP error encountered: fatal coding error >>>>> (CNS is in mode: SET ABORT=NORMal END) >>>>> ***************************************************** >>>>> ABORT mode will terminate program execution. >>>>> ***************************************************** >>>>> Program will stop immediately. >>>>> ============================================================ >>>>> Maximum dynamic memory allocation: 0 bytes >>>>> Maximum dynamic memory overhead: 8 bytes >>>>> Program started at: on >>>>> Program stopped at: 14:32:05 on 07-Jun-2010 >>>>> CPU time used: 0.0036 seconds >>>>> ============================================================ >>>>> >>>>> >>>>> With 4.2.1 (using gfortran), CNS fails at the linking stage with >>>>> "Undefined symbols:" errors. With 4.4, CNS compiles successfully, but >>>>> when executed produces a simple "segmentation fault" message. >>>>> >>>>> With the 11.1 Intel compilers, CNS compiles successfully, but fails on >>>>> execution: >>>>> >>>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred >>>>> Image PC Routine Line >>>>> Source >>>>> cns 000000010029C7BE _xtarmoin_ 1813 >>>>> xdeclare.f >>>>> cns 000000010029C68E _xreres_ 764 >>>>> xdeclare.f >>>>> cns 000000010003E04A _MAIN__ 167 cns.f >>>>> cns 000000010000184C Unknown Unknown >>>>> Unknown >>>>> cns 00000001000017E4 Unknown Unknown >>>>> Unknown >>>>> >>>>> >>>>> I have checked my shell stack limit, and to make sure, I set the shell >>>>> stacksize using "ulimit -s 65532" (which I believe is the upper limit >>>>> on Mac OSX) and by using the ifort linker option. Both of which made >>>>> no difference. >>>>> >>>>> I then added some compiler options in an attempt to obtain more >>>>> debugging information, including "-check bounds -g" and >>>>> "-heap-arrays". The following occurs on execution: >>>>> >>>>> forrtl: severe (408): fort: (2): Subscript #1 of the array HEAP has >>>>> value 155357288 which is greater than the up >>>>> per bound of 15 >>>>> >>>>> Image PC Routine Line Source >>>>> cns 000000010087410C Unknown Unknown >>>>> Unknown >>>>> cns 0000000100872C44 Unknown Unknown >>>>> Unknown >>>>> cns 000000010082BCCE Unknown Unknown >>>>> Unknown >>>>> cns 00000001007E36AA Unknown Unknown >>>>> Unknown >>>>> cns 00000001007E3AF7 Unknown Unknown >>>>> Unknown >>>>> cns 00000001002B48A4 _allhp_ 326 heap.f >>>>> cns 00000001002B7EC6 _heapvfy_ 93 >>>>> heapvfy.f >>>>> cns 0000000100071409 _MAIN__ 60 cns.f >>>>> cns 0000000100000D5C Unknown Unknown >>>>> Unknown >>>>> cns 0000000100000CF4 Unknown Unknown >>>>> Unknown >>>>> >>>>> >>>>> Any help/ideas would be very much appreciated. >>>>> >>>>> Best wishes, >>>>> Pryank >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Ethan A Merritt >>> Biomolecular Structure Center, K-428 Health Sciences Bldg >>> University of Washington, Seattle 98195-7742 >> >> Axel T. Brunger >> Investigator, Howard Hughes Medical Institute >> Professor of Molecular and Cellular Physiology >> Stanford University >> >> Web: http://atbweb.stanford.edu >> Email: [email protected] >> Phone: +1 650-736-1031 >> Fax: +1 650-745-1463 >> >> >> >> >> >> > Axel T. Brunger Investigator, Howard Hughes Medical Institute Professor of Molecular and Cellular Physiology Stanford University Web: http://atbweb.stanford.edu Email: [email protected] Phone: +1 650-736-1031 Fax: +1 650-745-1463
