[Mesa-users] MESA Installation | Crlibm Failure
RICHARD H D TOWNSEND
townsend at astro.wisc.edu
Fri Jun 22 05:58:38 EDT 2018
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
>
More information about the Mesa-users
mailing list