I was too hasty. The files which need patching aren’t even on my system. For instance, although htm.py is present, the to-be-patched file htmc.cc is nowhere to be found. (Either that or find(1) is seriously broken.)
Looks like the best approach may be to downgrade to gcc 7. Now to try that one.
Another miserable failure. This time the build complained about the lack of support for C++14. All this activity is strongly reminiscent of running Gentoo systems, an environment with which I have a good number of years of experience.
In principle I suppose that I may be able to dig up an otherwise unused workstation and install CentOS on it (to gain access to the tarballs) but that is another can of worms which I would rather not open.
Thank you for your patience and all your help but I’m going to have to give up at this point and wait for a new release. Any indication when that might happen?
I’ll investigate Docker. Good idea. Thanks. Another learning experience. Learning is good — it stops ones brain silting up.
However, a rummage around in my scrap heap turned up a laptop which I’d forgotten about. It must be a few years old because I inherited it from my late brother 18 months ago. It presently has Win10 installed, an OS of no interest whatsoever, and so I’ve no qualms about booting up a magazine cover disc with Fedora 29 on it. Even if it’s under-powered it may let me learn how to drive the LSST software while waiting for the next release.
“You are not expected to have known how to do this .”
Nice! I recognize the cultural reference:
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
All is good. Yay! I built the system in /usr/local/src running as root as hat’s how I’ve built most 3rd-party stuff over the years. Running the demo as an unprivileged user took a bit of tweaking with "chgrp -R pcl " and “chmod -R g+w” (I’m user pcl in group pcl) and the addition of symlinks to eups and loadLSST.bash from a working directory in ~pcl. There may be a more elegant way of doing this, or even a script to do it automagically, but I didn’t go looking for it. The step seemed to be needed because something wanted to write a temporary file in lsst_stack/stack/current/ups_db/. (An obvious question: is this wise? Should not /tmp or some other such temporary directory be used instead?)
After that the demo worked perfectly. I’m a happy bunny
Now to learn how to drive this stuff.
Once more, many thanks for your assistance and your patience in dealing with a clueless newbie.