[Mesa-users] MESA Installation | Crlibm Failure

Doryan Miller dorymill at iu.edu
Fri Jun 22 06:45:45 EDT 2018 

I did indeed to a clean before attempting a few times. The output is as
follows:

[dorymill at hm012 mesa]$ ./install

/N/u/dorymill/Karst/mesa/const
building const package.

makedepf90 -m %m.mod -I../public:../private const_def.f90 const_lib.f90 >
.depend
gfortran -Wno-uninitialized -fno-range-check -fmax-errors=12
-fprotect-parens -fno-sign-zero -fbacktrace -ggdb -finit-real=snan
-fopenmp  -std=f2008 -Wno-error=tabs -I../public -I../private
-I../../include -I/N/u/dorymill/Karst/mesasdk/include -Wunused-value
-Werror -W -Wno-compare-reals -Wno-unused-parameter -fimplicit-none   -O2
-c -ffree-form -x f95-cpp-input ../public/const_def.f90
gfortran -Wno-uninitialized -fno-range-check -fmax-errors=12
-fprotect-parens -fno-sign-zero -fbacktrace -ggdb -finit-real=snan
-fopenmp  -std=f2008 -Wno-error=tabs -I../public -I../private
-I../../include -I/N/u/dorymill/Karst/mesasdk/include -Wunused-value
-Werror -W -Wno-compare-reals -Wno-unused-parameter -fimplicit-none   -O2
-c -ffree-form -x f95-cpp-input ../public/const_lib.f90
ar crs libconst.a const_def.o const_lib.o
gfortran -Wno-uninitialized -fno-range-check -fmax-errors=12
-fprotect-parens -fno-sign-zero -fbacktrace -ggdb -finit-real=snan -fopenmp
-I../../make -I../../public -I../../../include -fbounds-check
-Wuninitialized -Warray-bounds  -c -ffixed-form -ffixed-line-length-132 -x
f77-cpp-input ../src/test_const.f
gfortran -fopenmp -o ../tester test_const.o -L../../make -lconst


FAILED


/N/u/dorymill/Karst/mesa/const/test
TEST FAILED -- compare test_output to tmp.txt


/N/u/dorymill/Karst/mesa/const
./build_and_test FAILED


With the utmost sincerity,
Doryan Miller

On Fri, Jun 22, 2018 at 5:58 AM, RICHARD H D TOWNSEND <
townsend at astro.wisc.edu> wrote:

> Hi Doryan --
>
> Can you post the screen output as well? Also, have you run './clean' in
> $MESA_DIR since you unset LD_LIBRARY_PATH?
>
> cheers,
>
> Rich
>
> > On Jun 22, 2018, at 10:56 AM, Doryan Miller <dorymill at iu.edu> wrote:
> >
> > Hello!
> >
> > It seems unsetting the LD_LIBRARY_PATH variable resulted in failure in
> the mesa/const module tester. The error file is included. The command
> "gfortran --version" yields version 7.2.0.
> >
> > With the utmost sincerity,
> > Doryan Miller
> >
> > On Fri, Jun 22, 2018 at 4:36 AM, RICHARD H D TOWNSEND <
> townsend at astro.wisc.edu> wrote:
> > Hi Doryan --
> >
> > This variable should be *unset* in order for the SDK to work properly.
> You can do this using the command
> >
> > unset LD_LIBRARY_PATH
> >
> > Because it can cause the sort of unexpected behavior you've encountered
> here, use of LD_LIBRARY_PATH is generally considered a bad idea. Here's an
> informative discussion of the issue:
> >
> > https://gms.tf/ld_library_path-considered-harmful.html
> >
> > Best wishes,
> >
> > Rich
> >
> > > On Jun 21, 2018, at 10:57 PM, Doryan Miller <dorymill at iu.edu> wrote:
> > >
> > > I could see how that would be a problem! Here's the output of the
> requested command. What should this variable be set to?
> > >
> > > [dorymill at hm012 mesa]$ echo $LD_LIBRARY_PATH
> > > /N/soft/rhel6/intel/16.0.1/compilers_and_libraries_2016.
> 1.150/linux/compiler/lib/intel64:/N/soft/rhel6/intel/16.0.1/compilers_and_
> libraries_2016.1.150/linux/mpi/intel64/lib:/N/soft/rhel6/
> intel/16.0.1/compilers_and_libraries_2016.1.150/linux/
> mpi/mic/lib:/N/soft/rhel6/intel/16.0.1/compilers_and_
> libraries_2016.1.150/linux/ipp/lib/intel64:/N/soft/rhel6/
> intel/16.0.1/compilers_and_libraries_2016.1.150/linux/
> compiler/lib/intel64:/N/soft/rhel6/intel/16.0.1/compilers_
> and_libraries_2016.1.150/linux/mkl/lib/intel64:/N/soft/
> rhel6/intel/16.0.1/compilers_and_libraries_2016.1.150/
> linux/tbb/lib/intel64/gcc4.4:/N/soft/rhel6/intel/16.0.1/
> debugger_2016/libipt/intel64/lib:/N/soft/rhel6/intel/16.0.
> 1/compilers_and_libraries_2016.1.150/linux/daal/lib/
> intel64_lin:/N/soft/rhel6/intel/16.0.1/compilers_and_
> libraries_2016.1.150/linux/daal/../tbb/lib/intel64_lin/
> gcc4.4:/N/soft/rhel6/intel/16.0.1/compilers_and_libraries_
> 2016.1.150/linux/daal/../compiler/lib/intel64_lin:/N/
> soft/rhel6/pcre/2-10.20/lib:/N/soft/rhel6/python/3.5.0/lib:
> /opt/moab/lib:/N/soft/rhel6/gcc/infrastructure/lib:/N/
> soft/rhel6/zlib/1.2.8/lib:/N/soft/rhel6/gcc/5.3.0/lib:/N/
> soft/rhel6/gcc/5.3.0/lib64:/opt/thinlinc/lib64:/opt/thinlinc/lib
> > >
> > > With the utmost sincerity,
> > > Doryan Miller
> > >
> > > On Thu, Jun 21, 2018 at 3:37 PM, RICHARD H D TOWNSEND <
> townsend at astro.wisc.edu> wrote:
> > > I can see the problem: the test program is linking against the runtime
> library (libgfortran) from Red Hat's installation of gcc 5.3, rather than
> the library provided with the SDK.
> > >
> > > To see why this might be, can you post the output from
> > >
> > > echo $LD_LIBRARY_PATH
> > >
> > > cheers,
> > >
> > > Rich
> > >
> > > > On Jun 21, 2018, at 8:21 PM, Doryan Miller <dorymill at iu.edu> wrote:
> > > >
> > > > The output for ldd on the crlibm tester was:
> > > >
> > > > ldd $MESA_DIR/crlibm/test/tester
> > > >
> > > >     linux-vdso.so.1 =>  (0x00007ffc253dc000)
> > > >     libgfortran.so.3 => /N/soft/rhel6/gcc/5.3.0/lib64/libgfortran.so.3
> (0x00007fb1b0d2f000)
> > > >     libm.so.6 => /lib64/libm.so.6 (0x0000003da2200000)
> > > >     libgomp.so.1 => /N/u/dorymill/Karst/mesasdk/lib64/libgomp.so.1
> (0x00007fb1b0ae3000)
> > > >     libgcc_s.so.1 => /N/u/dorymill/Karst/mesasdk/lib64/libgcc_s.so.1
> (0x00007fb1b08cb000)
> > > >     libquadmath.so.0 => /N/u/dorymill/Karst/mesasdk/lib64/libquadmath.so.0
> (0x00007fb1b068b000)
> > > >     libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003da2600000)
> > > >     libc.so.6 => /lib64/libc.so.6 (0x0000003da1a00000)
> > > >     librt.so.1 => /lib64/librt.so.1 (0x0000003da2e00000)
> > > >     libdl.so.2 => /lib64/libdl.so.2 (0x0000003da1e00000)
> > > >     /lib64/ld-linux-x86-64.so.2 (0x0000003da1600000)
> > > >
> > > >
> > > > with the utmost sincerity,
> > > > Doryan Miller
> > > >
> > > > On Thu, Jun 21, 2018 at 3:30 AM, RICHARD H D TOWNSEND <
> townsend at astro.wisc.edu> wrote:
> > > > HI Doryan --
> > > >
> > > > Can you post the output from the following command:
> > > >
> > > > ldd $MESA_DIR/crlibm/test/tester
> > > >
> > > > Many thanks,
> > > >
> > > > Rich
> > > >
> > > > > On Jun 20, 2018, at 10:45 PM, Doryan Miller <dorymill at iu.edu>
> wrote:
> > > > >
> > > > > Hi, Kulseep!
> > > > >
> > > > > Even with a stock bashrc profile, it doesn't work.
> > > > >
> > > > > With the utmost sincerity,
> > > > > Doryan Miller
> > > > >
> > > > > On Wed, Jun 20, 2018, 06:00 Kuldeep Verma <kuldeepv89 at gmail.com>
> wrote:
> > > > > Hi Doryan,
> > > > >
> > > > > This is related to the thread Rob mentioned. We recently fixed our
> problem. In our case, there was a conflict between the lines in our .bashrc
> file. You may try installing MESA with minimal information in your
> initializing script, and see if that works.
> > > > >
> > > > > Best wishes,
> > > > > Kuldeep
> > > > >
> > > > > On Wed, Jun 20, 2018 at 11:33 AM, Doryan Miller <dorymill at iu.edu>
> wrote:
> > > > > Will do. It appears that an older version of the SDK still isn't
> doing the trick.
> > > > >
> > > > > With the utmost sincerity,
> > > > > Doryan Miller
> > > > >
> > > > >
> > > > > On Wed, Jun 20, 2018 at 4:14 AM, Rob Farmer <r.j.farmer at uva.nl>
> wrote:
> > > > > Hi
> > > > > Please keep replies on the mesa-users list, this may help others
> or other may be able to help.
> > > > >
> > > > > A Previous user had the same issue
> > > > > https://lists.mesastar.org/pipermail/mesa-users/2018-
> February/008625.html
> > > > >
> > > > > They fixed it by switching to an older sdk, the November 2017 sdk,
> can you try that?
> > > > >
> > > > > Thanks
> > > > > Rob
> > > > >
> > > > >
> > > > > On Wed, 20 Jun 2018 at 02:52, Doryan Miller <dorymill at iu.edu>
> wrote:
> > > > > Scratch that! It's somehow working now! The output of ldd
> --version was:
> > > > >
> > > > > ldd (GNU libc) 2.12
> > > > > Copyright (C) 2010 Free Software Foundation, Inc.
> > > > > This is free software; see the source for copying conditions.
> There is NO
> > > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> > > > > Written by Roland McGrath and Ulrich Drepper.
> > > > >
> > > > > With the utmost sincerity,
> > > > > Doryan Miller
> > > > >
> > > > > On Tue, Jun 19, 2018 at 3:16 PM, Doryan Miller <dorymill at iu.edu>
> wrote:
> > > > > Hi, Rob
> > > > >
> > > > > No such command or executable was found, sadly.
> > > > >
> > > > > With the utmost sincerity,
> > > > > Doryan Miller
> > > > >
> > > > > On Tue, Jun 19, 2018, 10:19 Rob Farmer <r.j.farmer at uva.nl> wrote:
> > > > > Hi
> > > > >
> > > > > Thanks, for the all details. Can you send the output of:
> > > > > ldd --version
> > > > >
> > > > > Thanks
> > > > > Rob
> > > > >
> > > > > On Tue, 19 Jun 2018 at 12:36, Doryan Miller <dorymill at iu.edu>
> wrote:
> > > > > Hello!
> > > > >
> > > > > I'm trying to install MESA on a university machine on which I
> don't have root access on, and I'm getting failure in the crlibm module.
> The version of MESA I'm trying to install is 10108. The SDK version is the
> 27 January 2018 release for linux--the OS is Red Hat Linux 6.9.
> > > > >
> > > > > uname -a returns
> > > > >
> > > > > Linux hm012.karst.uits.iu.edu 2.6.32-696.30.1.el6.x86_64 #1 SMP
> Fri May 18 11:50:44 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
> > > > >
> > > > > gfortran -v returns sing built-in specs.
> > > > > COLLECT_GCC=/N/u/dorymill/Karst/mesasdk/bin/gfortran.exec
> > > > > COLLECT_LTO_WRAPPER=/gpfs/home/d/o/dorymill/Karst/
> mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
> > > > > Target: x86_64-pc-linux-gnu
> > > > > Configured with: /root/mesasdk-src/gcc/configure CC=gcc
> --build=x86_64-pc-linux-gnu --prefix=/root/mesasdk --with-gmp=/root/mesasdk
> --with-mpfr=/root/mesasdk --with-mpc=/root/mesasdk --enable-languages=c,c++,fortran
> --disable-multilib --disable-nls --disable-libsanitizer
> --enable-clocale=generic
> > > > > Thread model: posix
> > > > > gcc version 7.2.0 (GCC)
> > > > >
> > > > > The $MESA_DIR and $MESASDK_ROOT are set to ~/mesa and ~/mesasdk
> respectively, as they're located in my filesystem. The $PATH variable
> returns:
> > > > >
> > > > > /N/u/dorymill/Karst/mesasdk/bin:/usr/local/bin:/usr/local/
> sbin:/N/u/dorymill/Karst/mesasdk/bin:/usr/local/bin:/
> usr/local/sbin:/usr/lib64/qt-3.3/bin:/N/soft/rhel6/quotas:/
> N/soft/rhel6/intel/16.0.1/compilers_and_libraries_2016.
> 1.150/linux/bin/intel64:/N/soft/rhel6/intel/16.0.1/
> compilers_and_libraries_2016.1.150/linux/mpi/intel64/bin:/
> N/soft/rhel6/intel/16.0.1/debugger_2016/gdb/intel64_mic/
> bin:/N/soft/rhel6/perl/5.16.2/bin:/N/soft/rhel6/pcre/2-10.
> 20/bin:/N/soft/rhel6/python/3.5.0/bin:/opt/moab/bin:/N/soft/
> rhel6/gcc/5.3.0/bin:/usr/kerberos/sbin:/usr/kerberos/
> bin:/bin:/usr/bin:/opt/thinlinc/bin:/usr/local/bin:/
> usr/bin/X11:/usr/dt/bin:/usr/openwin/bin:/sbin:/usr/sbin:/
> usr/local/sbin:/N/u/dorymill/Karst/bin
> > > > >
> > > > > Also attached is the build.log file for the installation and the
> tmp.txt file from the crlibm directory. I've dug around as much as I can in
> trying to resolve this issue, so any help would be appreciated!
> > > > >
> > > > > With the utmost sincerity,
> > > > > Doryan Miller
> > > > > _______________________________________________
> > > > > mesa-users at lists.mesastar.org
> > > > > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > mesa-users at lists.mesastar.org
> > > > > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > mesa-users at lists.mesastar.org
> > > > > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > mesa-users at lists.mesastar.org
> > > > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > > >
> > >
> > >
> > > _______________________________________________
> > > mesa-users at lists.mesastar.org
> > > https://lists.mesastar.org/mailman/listinfo/mesa-users
> > >
> >
> >
> > <tmp.txt>_______________________________________________
> > mesa-users at lists.mesastar.org
> > https://lists.mesastar.org/mailman/listinfo/mesa-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180622/6474cc33/attachment.html>

More information about the Mesa-users mailing list