[mesa-users] Problems compiling new mesa version on supercomputer

Kevin Moore kmoore at physics.ucsb.edu
Mon Aug 6 21:55:35 EDT 2012


Hi Rich,

I tried using mesasdk-x86_64-linux-20120728, and it immediately failed giving the error:

gfortran -fno-range-check  -fopenmp  -I../public -I../private -I../../include -Wunused-value -Werror -W -fimplicit-none   -O2 -c -ffixed-form -ffixed-line-length-132 -x f77-cpp-input ../public/const_def.f
/projects/itp-group/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.7.2/f951: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /projects/itp-group/mesasdk/lib/libgmp.so.10)
make: *** [const_def.o] Error 1

This looks very similar to an error we saw in older versions of the SDK, although I don't remember how it was fixed. My relevant info is below:

[kmoore-ucsb at triton-43 itp-group]$ uname -a
Linux triton-43.sdsc.edu 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:22:04 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[kmoore-ucsb at triton-43 itp-group]$ gfortran --version
GNU Fortran (GCC) 4.7.2 20120711 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

[kmoore-ucsb at triton-43 itp-group]$ echo $MESASDK_ROOT
/projects/itp-group/mesasdk
[kmoore-ucsb at triton-43 itp-group]$ echo $PATH
/projects/itp-group/mesasdk/bin:/projects/itp-group/local/bin:/opt/openmpi/intel/mx/bin:/opt/intel/Compiler/11.1/072/bin/intel64:/opt/openmpi/bin:/usr/kerberos/bin:/usr/java/latest/bin:/usr/local/bin:/bin:/usr/bin:/opt/eclipse:/opt/ganglia/bin:/opt/ganglia/sbin:/opt/gold/bin:/opt/gold/sbin::/opt/torque/bin:opt/torque/sbin:/opt/maui/bin:/opt/maui/sbin:/opt/rocks/bin:/opt/rocks/sbin:/home/kmoore-ucsb/bin


In better news, Josiah's comment regarding reverting to the line in the makefile_header
LOAD_MATRIX = -lmtx -lconst -lmesaklu $(LOAD_LAPACK) $(LOAD_BLAS)

worked perfectly with the gcc 4.7.2 that I built myself (thanks, Josiah!). I didn't even think to look down that far in the file for more ifort specific lines...

Anyway, 4219 has successfully installed on Triton and ran through inlist_first_thing_to_try!

-Kevin

On Aug 5, 2012, at 2:29 PM, Richard Townsend wrote:

> Please could you go ahead and try it out with the latest release of the SDK -- and let me know if it does/doesn't work. I'll try hard to be extra-responsive to bug reports, given that the summer school is looming!
> 
> On Aug 5, 2012, at 4:25 PM, Kevin Moore wrote:
> 
>> It's one of the supercomputers at UCSD (http://tritonresource.sdsc.edu/)
>> 
>> I tried the SDK back in Jan. and it didn't work - likely due to the different architecture. I didn't attempt using the SDK this time, but could try it again anyway.
>> 
>> -Kevin
>> 
>> On Aug 5, 2012, at 2:18 PM, Richard Townsend wrote:
>> 
>>> Hi Kevin --
>>> 
>>> What is 'Triton'? And have you tried using the MESA SDK?
>>> 
>>> cheers,
>>> 
>>> Rich
>>> 
>>> On Aug 5, 2012, at 3:59 PM, Kevin Moore wrote:
>>> 
>>>> Hey all,
>>>> 
>>>> So you may remember me fighting with Triton to install mesa back in Jan. I eventually got version 3974 working, and have started trying to get a newer version (4219 specifically) compiled. I've tried compiling with ifort and 3 different versions of gcc that I've built (4.7.1, 4.7.2, and 4.8.0), all of which give (mostly different) compile-time errors. For reference, I typically compile mesa on my own machine using ifort 12.0.4 (20110503) and mesa 3974 compiled on Triton using ifort 11.1 (20100414). 
>>>> 
>>>> If anyone has any idea what these errors mean (or even better how to get rid of them), then I'd appreciate your help. 
>>>> 
>>>> ifort 11.1 (20100414) gives the following error while building num:
>>>> 
>>>> ifort  -vec-report0 -traceback -error-limit 6 -openmp -threads  -I../public -I../private -I../../include -warn all -warn nounused -implicitnone  -O2 -c -fixed -132 -fpp ../private/mod_newton.f
>>>> ../private/mod_newton.f(412): error #6731: Object is not a pointer object   [X]
>>>>      x(1:nvar,1:nz) => x_in1(1:neq)
>>>> ---------^
>>>> ../private/mod_newton.f(413): error #6731: Object is not a pointer object   [XOLD]
>>>>      xold(1:nvar,1:nz) => xold_in1(1:neq)
>>>> ---------^
>>>> ../private/mod_newton.f(414): error #6731: Object is not a pointer object   [EQU]
>>>>      equ(1:nvar,1:nz) => equ_in1(1:neq)
>>>> ---------^
>>>> ../private/mod_newton.f(415): error #6731: Object is not a pointer object   [XSCALE]
>>>>      xscale(1:nvar,1:nz) => xscale_in1(1:neq)
>>>> ---------^
>>>> ../private/mod_newton.f(416): error #6731: Object is not a pointer object   [Y]
>>>>      y(1:ldy,1:nsec) => y_in1(1:ldy*nsec)
>>>> ---------^
>>>> ../private/mod_newton.f(1615): error #6731: Object is not a pointer object   [A]
>>>>         A(1:ndiag,1:neq) => work(i:i+ndiag*neq-1); i = i+ndiag*neq
>>>> ------------^
>>>> (2450): catastrophic error: Too many errors, exiting
>>>> compilation aborted for ../private/mod_newton.f (code 1)
>>>> make: *** [mod_newton.o] Error 1
>>>> 
>>>> My guess is that this is some of the newer fortran 2003 stuff that hasn't been implemented in ifort 11.1 - if so then we should change the comment in makefile_header that says mesa needs at least ifort 11.1.
>>>> 
>>>> gfortran (4.7.1 & 4.7.2) gets through num, but gives the following error while building interp_2d:
>>>> 
>>>> gfortran -fopenmp -o ../tester test_renka790_sg.o test_renka790_db.o test_akima_sg.o test_akima_db.o interp_2d_support.o test_interp_2d.o -L../../make -linterp_2d -L../../../lib -lnum -linterp_1d -lutils -lalert -lconst -lmtx ../../../const/make/const_def.o ../../../const/make/const_lib.o -lmesaklu -lmesalapack -lmesablas
>>>> ../../../const/make/const_def.o: In function `__const_def_MOD_do_const_init':
>>>> const_def.f:(.text+0x0): multiple definition of `__const_def_MOD_do_const_init'
>>>> ../../../lib/libconst.a(const_def.o):const_def.f:(.text+0x0): first defined here
>>>> ../../../const/make/const_def.o:(.bss+0x460): multiple definition of `__const_def_MOD_omp_num_threads'
>>>> ../../../lib/libconst.a(const_def.o):(.bss+0x460): first defined here
>>>> ../../../const/make/const_def.o:(.bss+0x280): multiple definition of `__const_def_MOD_one_third_power'
>>>> ../../../lib/libconst.a(const_def.o):(.bss+0x280): first defined here
>>>> ../../../const/make/const_def.o:(.bss+0x80): multiple definition of `__const_def_MOD_pow_186'
>>>> etc...
>>>> 
>>>> gfortran 4.8.0 gave a different error much earlier (in mtx I think) which I didn't record, but it was an 'experimental' build so I guess I shouldn't be surprised.
>>>> 
>>>> Anyway, if anyone can think of anything else to try then let me know. Otherwise I think I'm giving up on this.
>>>> 
>>>> -Kevin
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and 
>>>> threat landscape has changed and how IT managers can respond. Discussions 
>>>> will include endpoint security, mobile security and the latest in malware 
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> mesa-users mailing list
>>>> mesa-users at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mesa-users
>>> 
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> mesa-users mailing list
>> mesa-users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa-users
> 
> 





More information about the Mesa-users mailing list