still to do:

- Allow enabling the workaround with an environment variable.
- Update documentation to mention the workaround.
- Test if compilation issue goes away with more recent OSI versions.
- Update LPBuildInstructions wiki page.

I removed the workaround and the buildbot is happy with it.

Whatever you prefer.

Yes, I can remove it. Should I open a new issue for this, reopen the branch, or
do the change in the default branch?

OK, I think roughly 5 months could be enough. Should we complete this now (i.e.,
get rid of the workaround)?

Either that or open a new one. As you prefer.

Fine with me. Should we leave this issue open until then?

As it doesn't do a lot of harm, I suggest keeping it in for a while an perhaps
getting rid of it when more people have had an opportunity to upgrade. Perhaps
get rid of it in a few months? I can set a reminder if you want.

The build instructions now recommend the new OSI version. Should we keep the
workaround?

I've updated the documentation (accidentally using the wrong account after
updating Salome's email address in the wiki config, in case you're wondering
about the notification message you received).

So the remaining step is to see if the workaround is still necessary with newer
OSI versions. If not, we should recommend a newer version and update our
troubleshooting info to reflect that this is only an issue with old versions.

This is of course related to issue680.

The code change is merged. It works as expected on my computers, and the
buildbot likes it too. The environment variables is named
DOWNWARD_USE_ISNAN_WORKAROUND, and I need to set

export DOWNWARD_USE_ISNAN_WORKAROUND=1

on my two machines that are running Ubuntu 16.04, but not on the ones that are
running older versions of Ubuntu.

I updated the summary to mention that we also need to update the documentation.
I'm currently testing the patch on various computers.

The attached patch should introduce the CMake variable (needs some renaming).

The OSI version we currently recommend in our build instructions (0.103.0) does
not work correctly with certain versions of GCC, such as the version of gcc 5.4
currently included in Ubuntu 16.04. Compilation fails with an error message that
is related to the visibility of the standard library function "isnan". It looks
like OSI seems to expect the function to be available as "isnan", but gcc 5.4
requires "std::isnan". This problem only occurs with a build using LP solvers.

We came up with a workaround, but this workaround breaks other version of gcc,
and it even breaks them in non-LP builds. The workaround is integrated in the
code (see lp/lp_internals.h), but because it breaks many setups, it must be
enabled manually by setting a preprocessor variable. Here is one way to do this:

(a) Add the following line to "build_configs.py" to define a new build
"release32_test":

release32_test = ["-DCMAKE_BUILD_TYPE=Release", "-DCMAKE_CXX_FLAGS='-m32
-DDOWNWARD_USE_GCC_5_4_OSI_WORKAROUND'"]

(b) Compile this new build with:

./build.py release32_test

(c) Use this new build with:

./fast-downward.py --build=release32_test OTHER_OPTIONS

We hope that the problem will go away with a newer OSI version, but this still
needs further testing.

In the, we want to make using the workaround less painful by adding a way to
enable it with an environment variable.