Hi,
In the past I’ve installed DMstack from source against Anaconda Python 2.3.0 (python 2.7.10) with no trouble. Today, I just tried it again, but running “bash newinstall.sh” fails saying the python on my system is incompatible. I just grabbed newinstall.sh via curl so I suspect this is the most up to date version.
LSST stack requires Python 2.7; you seem to have Python 2.7.10 :: Anaconda 2.3.0 (64-bit) on your
path (/opt/lsst/anaconda/2.3.0/bin/python).
Please set up a compatible python interpreter, prepend it to your PATH, and rerun this script.
Alternatively, we can set up the Miniconda2 Python distribution for you.
In addition to Python 2.7, some LSST packages depend on recent versions of numpy,
matplotlib, and scipy. If you don't have all of these, the installation may fail.
Using the Miniconda2 Python distribution will ensure all these are set up.
Miniconda2 Python installed by this installer will be managed by LSST's EUPS
package manager, and will not replace or modify your system python.
Would you like us to install the Miniconda2 3.19.0.lsst4 Python distribution (if unsure, say yes)? no
Thanks. After you install Python 2.7 and the required modules, rerun this script to
continue the installation.
Obviously I can work around this by just accepting the Miniconda install, and I probably will - but I’m just curious why this behavior seems to be new?
This is a bug. I think the script is getting confused by your /usr/bin/python. Can you set your PYTHON environment variable to your Anaconda python and try again please?
Yes, that fixed it, @timj Thank you!
One more silly question - due to the needs of the camera team - we’re presently still working with an older version of DMstack (Winter2015 - it’s a long story, we’re planning to upgrade with the next release of DMstack). The stack installation process is looking for C++11 support, we’re on SL6 with gcc4.4, so that support is unavailable, but likely Winter2015 doesn’t require it. Is there currently a sensible way to do an installation from source for an old version of the stack without this >= gcc4.8 requirement? I realize, this is likely an unrealistic request I just wanted to see if there’s a workaround. Perhaps I should just provide gcc4.8, Winter2015 should be fine with that, I believe: http://ls.st/faq I’ll give that a try.
Here’s the output from “bash newinstall.sh”:
Checking for C++11 support
Checking whether the C++ compiler works… no
C++11 extensions could not be enabled for compiler ‘unknown’
of course you cannot and should not remove C++11 from the current codebase - what I was wondering is if there was a way to download and compile old versions of the source code (in this case 10.1) using the tools that worked when that older version was released - which certainly did not require >= gcc 4.8. I successfully built 10.1 using devtoolset-2 (I’ve done the same for v11.0 which that same page of documentation suggested at the time of its release). What I am suggesting is that there may be a difference between supporting development and supporting users who deal with legacy systems and unfortunately legacy versions of the code.
so if I understand correctly, devtoolset-3 is now preferred because gcc 4.9 is the current target compiler? Is it anticipated DMstack will stick with 4.9.X for some time or are there plans for 5.x?
Oh. I see. The C++11 checks have made their way into things that are built as part of newinstall.sh before eups distrib install is even called. I don’t think we expected that. It’s this line in newinstall.sh:
########## Install the Basic Environment
if true; then
echo "Installing the basic environment ... "
$cmd eups distrib install --repository="$EUPS_PKGROOT" lsst
fi
which installs lsst which is a mini package that installs sconsUtils and sconsUtils now pre-emptively complains when a C++11 compiler is not available (it used to be that nothing complained but things simply broke later in the build). In your case you want to see your environment and then install v10.1 which itself does not rely on C++11 compiler and will use an older sconsUtils.
We need to ponder. I guess that one quick fix is to tweak the eups distrib install line there to install the lsst package from 10.1 (add -t 10_1 to the command).
There are no plans for 5.x yet. We have been discussing the option of mandating 4.9 as minimum rather than 4.8 so as to get some important C++11 bug fixes. This would require SL7 users also switch to devtoolset-3.
I just wanted to see if there’s a workaround. Perhaps I should just provide gcc4.8, Winter2015 should be fine with that, I believe: