Thanks!

The limitation is already documented on the installation instructions for CPLEX.
They say:
  If you need 32 bit builds, you also have to install the 32 bit version of
CPLEX and use 
  the environment variable DOWNWARD_CPLEX_ROOT32 to identify its location.
However, CPLEX 
  will no longer support 32-bit builds starting with version 12.7 and previous
32-bit 
  versions of CPLEX are not compatible with recent OS versions. If you get
segmentation 
  faults with 32-bit CPLEX builds, try to build one of the sample programs that
come with 
  CPLEX to see if it is installed correctly.

Thanks, Jendrik, but I think that the discussion has moved on since last year
and we are now committed to removing the 32-bit build. I cannot realistically
see us reverse the course unless someone

1) finds a way of making CPLEX work with 32 bits again or finds a working
alternative to CPLEX that works with 32 bits and has comparable performance, and

2) volunteers to take over maintenance of all things 32-bit-related.


Regarding this particular issue, I think the resolution is that we cannot fix it
because it is a CPLEX issue and IBM has decided not to fix it by discontinuing
the 32-bit build. So I suggest we mark this issue as "resolved": it's a known
limitation, no longer an open issue. Before we mark the issue as resolved, we
should document this limitation on the wiki somewhere.

Florian, you understand the details of this best. Could you make such a wiki update?

I opened issue754 for the discussion about 32-bit builds.

This is precisely the discussion that I think should not be hidden away in an
issue called "segfaults with 32-bit CPLEX build".

Do we want to actively prevent a 32-bit build? I thought we are just talking
about changing the default?

With cmake we have little control over the bit width. We can detect what it is
at cmake runtime and exit with an error if it is not what what we expected. We
currently do this if we detect a 64 bit build but the option "Yes, I know what
I'm doing. I really want a 64 bit build." is not set. Are you suggesting to do
something like this for the 32 bit build?

I wouldn't wait. People are always in a better position to influence a decision
if they can participate in the process early. Let's avoid a fait accompli situation.

One could argue that everyone had the chance to join issue213 before, but most
of them weren't around when it was opened in 2011, so they got no notification,
and also the title of the issue only suggests improving the 64-bit build, not
getting rid of the 32-bit build.

Issue213 is about the memory usage in the 64bit build. Should we wait with the
announcement on downward-dev until we have some up-to-date data?

I think our best time investment might be to move to 64-bit builds. This would
have the additional advantage of significantly simplifying our build
requirements and infrastructure.

In the last tests we made, 64-bit builds already tended to be faster than 32-bit
builds, but memory usage was an issue. Since that time our data structures and
compiler versions have changed a lot, I think. So we definitely need more tests.
These should cover a broad spectrum of search algorithms and heuristics.

If you agree that this is a reasonable goal to pursue, I think we should open a
new issue for this and announce it to downward-dev because it is a rather
high-level change.

We have seen segfaults with 32-bit CPLEX on several computers even when just
building a small CPLEX test program. After some tests, I suspect that this is
caused by a bug in CPLEX that shows up in combination with newer binutils
versions. With the binutils from Ubuntu 16.10 linking the sample code
dynamically fails and complains about the cplex library (direct GOT relocation
R_386_GOT32 against `UCNV_FROM_U_CALLBACK_STOP_44_cplex' without base register
can not be used when making a shared object). Older versions do not detect this
and then crash at runtime.

It is unlikely that IBM will fix this in the old version. Newer versions of
CPLEX (>= 12.7) no longer support 32-bit builds. We can currently still run
experiments with CPLEX on the grid because they still have an old enough version
of binutils, but in the long run, we probably have to switch to 64 bit.

I opened this issue mainly so we can discuss how to handle this.

For reference, here it the discussion in the IBM forum:
https://www.ibm.com/developerworks/community/forums/html/topic?id=d671bf69-0222-4058-a935-f98c7ce7cba9