Kevin R. Thornton

I worry that the fix is incorrect when GCC is not the compiler. The 'gcc-ar' bit is a red flag. The SO post talks about static libs, but slim can't...

I'm sure a conditional application is possible, but I'm not sure how. You'll have to Google that one. I am much more familiar with GNU autotools than I am with...

Fine to comment it out for the time being. There must be a way to apply this "fix" if the compiler is GCC, though, and presumably there is CI in...

@bhaller It is interesting to note that this issue seems only to be reported from CentOS users so far?

That initial report on Ubuntu 14 isn't really reproducible. That version is now 5 years old and the tool chain is ancient. Everything works just fine on all current versions...

Looking back on the first report: 14.04 worked, but 16.04 didn't. That's odd, IMO. But, things happen. My development box where fwdpy11 is tested is 16.04 with GCC 5.5 and...

RHEL and centos are "the same". The former is the Enterprise version of the latter. On Mon, May 13, 2019, 7:11 PM Ben Haller wrote: > Also someone on Red...

> Also someone on Red Hat Enterprise Linux Server release 6.6 (Santiago), above. Seems like a pretty mixed bag. I don't know why it bites particular people and not others....

One option for a short-term fix is to allow opt-in for FLTO. The default would be `OFF`, and then invoking something like `cmake . -DUSE_FLTO=1` would enable it.

For the record, I caught this b/c using msprime instead of discoal made the accuracy of diploSHIC "quite poor" and I tracked it down to this diff in the number...