Build failure for meas_algorithms 17.0.1

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?

gcc 7 definitely supports C++14, so something else is fishy. Let me get you specific instructions on how to patch esutil, though.

(Another alternative could be to run docker, in which case you can use our containers directly.)

In Ubuntu 19.04:

$ apt-get update --fix-missing
$ # note addition of rsync to the list below
$ apt-get install     bison     ca-certificates     cmake     curl     default-jre     flex     gettext     git     libbz2-dev     libcurl4-openssl-dev     libfontconfig1     libglib2.0-dev     libncurses5-dev     libreadline6-dev     libx11-dev     libxrender1     libxt-dev     m4     make     perl-modules    rsync     zlib1g-dev
$ cd
$ mkdir -p lsst_stack
$ cd lsst_stack
$ curl -OL https://raw.githubusercontent.com/lsst/lsst/17.0.1/scripts/newinstall.sh
$ bash newinstall.sh -ct
$ source loadLSST.bash
$ # eups distrib install -t v_17_0_1 --onlydepend esutil (not actually necessary in this case)
$ git clone https://github.com/lsst/esutil
$ cd esutil
$ mkdir patches
$ cd patches
$ curl -O https://github.com/esheldon/esutil/commit/88a715.patch
$ cd ..
$ eupspkg -er fetch
$ eupspkg -er prep
$ eupspkg -er config
$ eupspkg -er build
$ # autodetected version is not quite right; fix it manually
$ eupspkg -er VERSION=0.6.2.5.lsst2+1 install
$ eupspkg -er VERSION=0.6.2.5.lsst2+1 decl
$ cd ..
$ eups distrib install -t v17_0_1 lsst_distrib

(I think this should work; my install is only halfway through, but that’s all I have time for right now.)

You are not expected to have known how to do this :smiley:.

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);
}

JAUH. I’ve been hacking Unix since 1983.

Paul

Looking good!

Already 112/128 built, including the previously failing case.

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 :smile:

Now to learn how to drive this stuff.

Once more, many thanks for your assistance and your patience in dealing with a clueless newbie.

Paul

If that’s what I think it is, it isn’t a temporary file. But the system can be configured to work without it. https://dev.lsstcorp.org/trac/wiki/EupsTips#LockProblems