[Mesa-users] MESA Installation | Crlibm Failure

Sun Jun 24 17:49:18 EDT 2018

Interesting. Server might've been down for a sec. I've been trying all
solutions on both the 10398 release and the 10108 release.

With the utmost sincerity,
Doryan Miller

On Sun, Jun 24, 2018, 17:31 RICHARD H D TOWNSEND <townsend at astro.wisc.edu>
wrote:

> Hi Doryan --
>
> You may not have seen my response, as your mailserver bounced my message
> (no such user -- wtf?).
>
> So, see below...
>
> cheers,
>
> Ricb
>
> Begin forwarded message:
>
> *From: *Richard Townsend <townsend at astro.wisc.edu>
> *Subject: **Re: [Mesa-users] MESA Installation | Crlibm Failure*
> *Date: *June 22, 2018 at 12:55:19 PM GMT+1
> *To: *Doryan Miller <dorymill at iu.edu>
> *Cc: *"mesa-users at lists.mesastar.org" <mesa-users at lists.mesastar.org>
>
> Hmm, that's puzzling.
>
> Can I ask what version of MESA you are using?
>
> cheers,
>
> Rich
>
> On Jun 22, 2018, at 11:45 AM, Doryan Miller <dorymill at iu.edu> wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/20180624/ce330618/attachment.html>