On RH6-64, with devtoolset-3 enabled, and my own vanilla Anaconda2 4.3.1 installed, I receive the following error after running eups distrib install -t v13_0 lsst_distrib --nolocks
[ 37/93 ] tmv 0.73+5 done.
...
[ 44/93 ] galsim 1.4.1.lsst3 ...
***** error: from /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.log:
TMV version is 0.73
Using TMV_LINK file: /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/Linux64/tmv/0.73+5/share/tmv/tmv-link
-L/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/Linux64/tmv/0.73+5/lib -ltmv -lpthread -fopenmp
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage... yes
Checking if we can build against Python...
Unable to build a python loadable module using the python executable:
/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/bin/python,
the library name libpython2.7.so,
and the libdir /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/lib.
Nor did any of the known variations on this work.
If these are not the correct library name or location, you can tell scons
the correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
Please fix the above error(s) and rerun scons.
Note: you may want to look through the file INSTALL.md for advice.
Also, if you are having trouble, please check the INSTALL FAQ at
https://github.com/GalSim-developers/GalSim/wiki/Installation%20FAQ
+ exit -4
eups distrib: Failed to build galsim-1.4.1.lsst3.eupspkg: Command:
source /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/eups/bin/setups.sh; export EUPS_PATH=/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0; (/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.sh) >> /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.log 2>&1 4>/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.msg
exited with code 252
As suggested I read the Install.md file and tested which python modules I had available - I am missing pyfits, future, and the optional starlink.Ast. This page just lists matplotlib and scipy as dependencies: https://pipelines.lsst.io/install/newinstall.html#source-install-py-deps
I’ve now installed pyfits and future and restarted the build… it failed in the same way. To be fair, perhaps I should start fresh or at least clean out the galsim build products and try again.
If I allow newinstall to install Miniconda, the build is successful, so this is likely related to my use of a user installed Anaconda.
The galsim dependencies are part of the build (future and pyfits) so they are not the problem. The fact that you did not have future installed on your python suggests to me that you are not using a miniconda recently installed by newinstall.sh and have an old one. I am wondering if your python is out of date and if you need to do conda update python as discussed in DM-7620 (which I thought was a Mac problem but it’s worth a try).
At this point I would typically shrug and create a conda env using the lsstsw package list and carry on by using that version to do this installation of v13_0 (of even more likely just let newinstall handle the miniconda installation for me). Is it wrong for me to assume that I really can’t use my own Anaconda installation? I note I don’t have nomkl… and hence my numpy, scipy etc are not nomkl either…
Unfortunately galsim isn’t reporting the actual error message coming from the linker so it’s hard to work out what the problem is. Your anaconda versions are irrelevant for the link test. I assume the library path it is complaining about is the library path you are expecting it to be using.
It would be great if you could try a clean install with a miniconda installed from newinstall.sh just to see if this is a fundamental issue with your system or a weird issue with your pre-installed NFS-mounted anaconda.
@rmjarvis is there an easy way to convince GalSim to tell us what the link problem really is?
As I think I noted at the end of my original post - the build is successful if I ignore my own Anaconda installation and allow newinstall to handle the miniconda installation.
Concerning nomkl, if I ever hope to use my own Anaconda installation, I should install nomkl and then set about obtaining the proper nomkl versions of numpy, scipy?
At this point - I fully expect I’ll retreat and just let newinstall just pull in miniconda… but there’s a part of me that would like to be able to use my own Anaconda python installation as long as I understand what it is that is necessary to do so.
Yes. That’s unfortunately what is needed. Conda will work out what needs changing.
Agreed. It seems the only substantive differences are python 2.7.12 vs python 2.7.13 and conda 4.2.13 vs conda 4.3.14. One investigative route is to update the LSST-installed miniconda to use the newer python and newer conda and see if galsim fails to build with that configuration.
@rmjarvis is there an easy way to convince GalSim to tell us what the link problem really is?
Look in the file gs_error.txt, which shows all the various compile and link attempts GalSim made and their outputs. We don’t report them all to the screen, since it typically tries a number of different possibilities, so it can be a little tricky figuring out which compilation attempt is the one that should have worked on your system. But all the attempts are in that file, along with a bunch of other useful information to help diagnose installation failures.
@heather999 If you want to send me that file, I can take a look and try to figure out what the problem is.
I will say off the cuff that the most common problem with our installation is boost. Especially in connection to Anaconda. cf. this FAQ entry.
Unfortunately, I’m not sure I understand the error. When it tries to print out what happens when this command is run, it says:
Output of the command '/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/bin/python < .sconf_temp/conftest_37' is:
bash: /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/bin/python < .sconf_temp/conftest_37: No such file or directory
So is conftest_37 not there? (That’s just a text file, so why would that write have failed?) Or does that python executable not exist? (Weird, because I’m pretty sure it worked earlier in the SCons session.) I’m not sure what to make of that. Everything after that that it tries with different possible library options fails with the same error.
So maybe you can look in your .sconf_temp directory at the different conftest_36 and conftest_37 items. Sometimes running the commands yourself from the command line rather than from within SCons makes it clearer what the problem actually is.
Now that I have nomkl installed which did indeed pull in the right numpy and scipy… I’m starting a fresh build. I’ll send along the results of that later today… and if there continue to be failures, I’ll try to rerun some of those scons steps at the command line.
Unfortunately, it seemed to fail in the same fashion
bash-4.1$ eups distrib install lsst_distrib -t v13_0 --nolocks
[ 1/93 ] apr 1.5.2 done.
[ 2/93 ] cfitsio 3360.lsst4 done.
[ 3/93 ] doxygen 1.8.5.lsst1 (already installed) done.
[ 4/93 ] eigen 3.2.5.lsst2 done.
[ 5/93 ] fftw 3.3.4.lsst2 done.
[ 6/93 ] gsl 1.16.lsst3 done.
[ 7/93 ] mariadbclient 10.1.21.lsst1 done.
[ 8/93 ] minuit2 5.34.14 done.
[ 9/93 ] mpich 3.2.lsst1 done.
[ 10/93 ] python 0.0.6 (already installed) done.
[ 11/93 ] swig 3.0.10 done.
[ 12/93 ] xpa 2.1.15.lsst3 done.
[ 13/93 ] activemqcpp 3.9.0.lsst2+3 done.
[ 14/93 ] apr_util 1.5.4 done.
[ 15/93 ] astropy 0.0.1.lsst2+2 ...
Using externally provided astropy v1.3.
[ 15/93 ] astropy 0.0.1.lsst2+2 done.
[ 16/93 ] boost 1.60.lsst1+1 done.
[ 17/93 ] mpi 0.0.1+2 done.
[ 18/93 ] numpy 0.0.3+1 ...
Using externally provided numpy v1.11.3.
[ 18/93 ] numpy 0.0.3+1 done.
[ 19/93 ] pykg_config 1.3.0+1 done.
[ 20/93 ] python_d2to1 0.2.12.lsst2+1 done.
[ 21/93 ] python_future 0.15.2+2 done.
[ 22/93 ] python_mysqlclient 1.3.7.lsst1+8 done.
[ 23/93 ] python_psutil 4.1.0+3 done.
[ 24/93 ] pyyaml 3.11.lsst1+3 done.
[ 25/93 ] scons 2.5.0.lsst2+1 (already installed) done.
[ 26/93 ] sqlalchemy 1.0.8.lsst3+3 done.
[ 27/93 ] wcslib 5.13.lsst1 done.
[ 28/93 ] astrometry_net 0.67.123ff3e.lsst1+1 done.
[ 29/93 ] esutil 0.6.0+1 done.
[ 30/93 ] log4cxx 0.10.0.lsst7 done.
[ 31/93 ] matplotlib 0.0.4 ...
Using externally provided matplotlib v2.0.0.
[ 31/93 ] matplotlib 0.0.4 done.
[ 32/93 ] mpi4py 2.0.0+2 done.
[ 33/93 ] ndarray 1.3.0 done.
[ 34/93 ] scipy 0.0.1.lsst1+3 ...
Using externally provided scipy v0.19.0.
[ 34/93 ] scipy 0.0.1.lsst1+3 done.
[ 35/93 ] sconsUtils 13.0 (already installed) done.
[ 36/93 ] stsci_distutils 0.3.7.lsst1+2 done.
[ 37/93 ] tmv 0.73+5 done.
[ 38/93 ] astrometry_net_data 10.0+89 done.
[ 39/93 ] base 13.0 done.
[ 40/93 ] lmfit 0.9.3+4 done.
[ 41/93 ] lsst 13.0 (already installed) done.
[ 42/93 ] psfex 13.0 done.
[ 43/93 ] pyfits 3.4.0+7 done.
[ 44/93 ] galsim 1.4.1.lsst3 ...
***** error: from /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.log:
TMV version is 0.73
Using TMV_LINK file: /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/Linux64/tmv/0.73+5/share/tmv/tmv-link
-L/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/Linux64/tmv/0.73+5/lib -ltmv -lpthread -fopenmp
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage... yes
Checking if we can build against Python...
Unable to build a python loadable module using the python executable:
/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/bin/python,
the library name libpython2.7.so,
and the libdir /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/lib.
Nor did any of the known variations on this work.
If these are not the correct library name or location, you can tell scons
the correct names to use with the flags EXTRA_LIB_PATH and/or EXTRA_LIBS.
Please fix the above error(s) and rerun scons.
Note: you may want to look through the file INSTALL.md for advice.
Also, if you are having trouble, please check the INSTALL FAQ at
https://github.com/GalSim-developers/GalSim/wiki/Installation%20FAQ
+ exit -4
eups distrib: Failed to build galsim-1.4.1.lsst3.eupspkg: Command:
source /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/eups/bin/setups.sh; export EUPS_PATH=/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0; (/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.sh) >> /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.log 2>&1 4>/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/DMstack/v13_0/EupsBuildDir/Linux64/galsim-1.4.1.lsst3/build.msg
exited with code 252
The gs.error file again mentions a number of conftest_* files as missing, but they exist and have content, for example:
Output of the command '/nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/a
naconda/4.3.1/bin/python < .sconf_temp/conftest_90' is:
bash: /nfs/farm/g/lsst/u1/software/redhat6-x86_64-64bit-gcc44/anaconda/4.3.1/bin
/python < .sconf_temp/conftest_90: No such file or directory
bash-4.1$ more EupsBuildDir/Linux64/galsim-1.4.1.lsst3/galsim-1.4.1.lsst3/.sconf_temp/conftest_100
import sys
sys.path.append('.sconf_temp/conftest_99_mod')
import check_python
print(check_python.run())
bash-4.1$ ls EupsBuildDir/Linux64/galsim-1.4.1.lsst3/galsim-1.4.1.lsst3/.sconf_temp/conftest_99_mod/
check_python.so
so I tried re-running
bash-4.1$ python < .sconf_temp/conftest_100
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
ImportError: libtmv_symband.so.0: cannot open shared object file: No such file or directory
That library exists, I just don’t have the environment set up as the build does even though I’m in the same session where “eups distrib install” failed. Short of duplicating what I see in gs.error by hand, is there an easy way to get my environment arranged properly so I can run some of these commands without scons?
I’ve started to poke around, but I suspect you’ll see the problem a lot faster.