Status: To Do
Fix Version/s: None
Team:Data Release Production
On 14-03-2017 Jim Bosch reported the following issue on Slack:
I can't seem to build from source against the first weekly (w_2017_11) with pybind11 on lsst-dev. The failure mode is a segfault that looks like some kind of environmental library version mismatch. That weekly isn't yet installed in the shared stack on tiger, so I can't test there, and it's possible my shared-stack-fu is so rusty I'm doing something stupid. I'm hoping someone else can tell me what I'm doing wrong or try to reproduce, on lsst-dev01:
```scl enable devtoolset-3 git19 bash
git clone firstname.lastname@example.org:lsst/utils.git
git checkout w.2017.11
setup -v -r . -T w_2017_11
I have not been able to generate a similar failure with w_2017_10, the last Swig weekly.
and reported that Yusra AlSayyad was seeing the same issue.
John Swinbank responded:
Looks like the error there is coming from the use of devtoolset-3. That’s not strictly necessary on lsst-dev01: it runs CentOS 7 which ships with gcc 4.8, and that’s what we use to build the shared stack. Enabling devtoolset-3 gets you gcc 4.9; building with that seems to be causing the segfault.
Since we’re only seeing this with the pybind stack, it would be nice to understand exactly what special requirements that places on the toolchain (no mixing gcc minor versions?!) and make sure we document that both for lsst-dev (at https://developer.lsst.io/services/lsst-dev.html#select-appropriate-developer-tools) and the stack in general.
Investigate this further and file a bugreport upstream.