[Mesa-users] MESA Installation | Crlibm Failure

Mon Jun 25 02:11:44 EDT 2018

Hi all. I remember asking about this at one point because I was considering
trying out the intel compilers along side the gnu compilers. It seems
according to the library path that you have both installed and I believe
they don't play well together, in that you can't link to both at the same
time. Could this be contributing to the path confusion somehow?

On Mon, Jun 25, 2018 at 5:49 AM Doryan Miller <dorymill at iu.edu> wrote:

> 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
>>
>>
>>
>> _______________________________________________
> mesa-users at lists.mesastar.org
> https://lists.mesastar.org/mailman/listinfo/mesa-users
>
>

-- 
Amber Lauer
Postdoctoral Researcher
Triangle Universities Nuclear Lab
Duke University
amber.lauer at tunl.duke.edu <amber.lauer at duke.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20180625/a26b3375/attachment.html>