[Mesa-users] Fwd: MESA Installation | Crlibm Failure

amber lauer amberlauer at gmail.com
Wed Jun 27 01:59:18 EDT 2018 

---------- Forwarded message ---------
From: amber lauer <amberlauer at gmail.com>
Date: Wed, Jun 27, 2018 at 1:58 PM
Subject: Re: [Mesa-users] MESA Installation | Crlibm Failure
To: <dorymill at iu.edu>


There are some very good devs on the list that know more than me about
this. However, I can still give you some advice, but it may be a more
difficult way than someone else would come up with.

Assuming you 1) paid for the intel compilers, and 2) have the capability to
reinstall, I would use the included uninstall.sh script and remove it
entirely. Then I would investigate the various scripts and options to
reinstall and see if there is a built in option to only link to them at
will, rather than permanently. If not I would look into the installation
scripts and code and find where it adds to your library path (either system
wide or in your .bashrc) and comment this out and also use it as a guide to
write a script to link at will.

Bash commands are the only way I know how to modify the library path,
though there may be system commands that allow you to do it without
uninstalling. If it's dire that you have it you might want to investigate
this.

If you don't need the intel compilers right now, I would uninstall them and
get MESA working, then worry about the rest later.

I have seen this situation with another proprietary compiler, although it
was on OSX. Somehow, despite your best attempts to link to the SDK, the
proprietary compiler overrules it and finds a way to take precedence.

On Wed, Jun 27, 2018 at 7:54 AM Doryan Miller <dorymill at iu.edu> wrote:

> Hi, Amber.
>
> This seems like the case. Any solutions on pointing mess to just one?
>
> With the utmost sincerity,
> Doryan Miller
>
> On Mon, Jun 25, 2018, 02:12 amber lauer <amberlauer at gmail.com> wrote:
>
>> 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>
>>
>

-- 
Amber Lauer
Postdoctoral Researcher
Triangle Universities Nuclear Lab
Duke University
amber.lauer at tunl.duke.edu <amber.lauer at duke.edu>


-- 
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/20180627/54242333/attachment.html>

More information about the Mesa-users mailing list