Since we're moving the build instructions from the wiki into the repo and don't want to add the latest version of the patched COIN configure script to the repo, I'm uploading it here.

Looks good to me.  I ran airports/p24 with the search setting you supplied.  Looks 
good, and validate passed the plan.

Oops... I missed Roberts msg1941. It would make sense to also test the planner
in action. To do so, you'd also need to build the preprocessor (just "make" from
the preprocessor directory) and then run the three stages of the planner in a
suitable sequence. I assume everyone's familiar with the three basic steps
(right?) and that the interesting part is just the command-line for the search
component, which should be something like (without the line breaks):

$ ./downward --search
'astar(lmcount(lm_merged([lm_rhw(),lm_hm(m=1)]),admissible=true,optimal=true),mpd=true)'
< output

It'd be good to also try with assertions enable. For that, compile again with

$ make USE_LP=1 debug
(no need to make clean; the targets and object files are different)

and then run the above command with "downward-1-debug" in place of "downward".

Wonderful, thanks everyone! Merged to the default branch.

I'm marking this resolved now. (I'm not worried enough about prettifications to
the configure output, which is only so much mumbo-jumbo to me anyway -- my hope
is that we'll see a proper fix landed upstream in the COIN-OR repository in the
not-too-far future.)

Did the clean checkout and build, and the build went fine.

Is the following right?

configure: Checking for proper name for isfinite().
checking for finite... yes
configure: Using finite as isfinite()

I suspect that this is just a badly written message (if the constant name is 
"finite" and the value is "isfinite", then this is topsy-turvy).  Probably 
should be rewritten to less-ambiguously say "The value of finite is isfinite()."

Do you have a command line that will [Test that the planner works.]?

I got your --search argument, below, but it would help to know of an example in 
your benchmarks to run it against that will actually exercise the linear 
programming.

I will build on my Mac now and will let you know when all done.

BTW, it would probably help to have someone with Lion test it, as well.  I have 
been avoiding the upgrade for fear of breaking something I need, so I am still 
running Snow Leopard (10.6).

confirmed

On Mon, Nov 14, 2011 at 4:10 PM, Malte Helmert
<downward.issues@googlemail.com> wrote:
>
> Malte Helmert <malte.helmert@unibas.ch> added the comment:
>
> Pushed (again, so far only to the branch).
> Can the Mac users do the following steps and confirm that it works?
>
> $ hg clone http://hg.fast-downward.org issue295-testdir
> $ cd issue295-testdir
> $ hg update issue295
> $ cd src
> $ cd search
> $ make USE_LP=1 all
> [Test that the planner works.]
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________
>

Pushed (again, so far only to the branch).
Can the Mac users do the following steps and confirm that it works?

$ hg clone http://hg.fast-downward.org issue295-testdir
$ cd issue295-testdir
$ hg update issue295
$ cd src
$ cd search
$ make USE_LP=1 all
[Test that the planner works.]

I just tested on my Mac (Snow Leopard, 10.6.8), and it built fine with Andrew's 
configure file.

I'll try to integrate it if and once I can get one more success report from OS X
users.

With Emil's help, we now have a CoinUtils/configure file that works both on his
OS X machine, and on my Ubuntu Linux machine.  The file is at:

http://www.inf.kcl.ac.uk/staff/andrew/configure

..and has an extra check for std::isfinite, before the pre-existing checks for
finite, isfinite and _finite.  If people could double-check it works on their
favourite platforms, that'd be great :).

I will try to get to this tomorrow if no one beats me to it.
Cheers,
R

Sent from my iPad

On Nov 12, 2011, at 13:20, Andrew Coles <downward.issues@googlemail.com> wrote:

> 
> Andrew Coles <andrew.coles@kcl.ac.uk> added the comment:
> 
> This issue is getting stranger by the minute....  Apparently, the availability
> of finite and isfinite as global functions on OS X depends on a whole host of
> factors: including <cmath> and <math.h> breaks it; changing the compiler flags
> for language compatibility changes it; which, in turn, depends on the system
> compiler flags a given invocation of the compiler picks up; and so on.  The only
> thing which seems to be reliable is that including <cmath> makes std::isfinite
> available, so long as one explicitly gives it the std namespace.
> 
> So, I need a volunteer with a Mac.  A replacement CoinUtils/configure is at:
> 
> http://www.inf.kcl.ac.uk/staff/andrew/configure
> 
> It replaces the check for finite with a check for std::isfinite (so don't think
> about using it on Linux ;) ).  Copy it over CoinUtils/configure, run configure
> from the top-level Osi-... directory, and send me CoinUtils/config.log via email
> (firstname.lastname at kcl.ac.uk) so I can see what the impact of the change is.
> 
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________

This issue is getting stranger by the minute....  Apparently, the availability
of finite and isfinite as global functions on OS X depends on a whole host of
factors: including <cmath> and <math.h> breaks it; changing the compiler flags
for language compatibility changes it; which, in turn, depends on the system
compiler flags a given invocation of the compiler picks up; and so on.  The only
thing which seems to be reliable is that including <cmath> makes std::isfinite
available, so long as one explicitly gives it the std namespace.

So, I need a volunteer with a Mac.  A replacement CoinUtils/configure is at:

http://www.inf.kcl.ac.uk/staff/andrew/configure

It replaces the check for finite with a check for std::isfinite (so don't think
about using it on Linux ;) ).  Copy it over CoinUtils/configure, run configure
from the top-level Osi-... directory, and send me CoinUtils/config.log via email
(firstname.lastname at kcl.ac.uk) so I can see what the impact of the change is.

hg identify says:

c00af7f08291+ (issue295)

tried doing a clean build and copying the configure patch, same
problem. I think the error is coming from the following:

checking whether isfinite is declared... no
checking whether finite is declared... yes

even though the script checks first for "isfinite", it appears to it
to be undeclared, and finite appears to be declared. but this is not
true later when trying to compile the header. no idea why this would
happen.

On Sat, Nov 12, 2011 at 5:36 PM, Malte Helmert
<downward.issues@googlemail.com> wrote:
>
> Malte Helmert <malte.helmert@unibas.ch> added the comment:
>
> Emil, what does
> $ hg identify
> say? Are you 100% that the previous contents of lp/coin were deleted? Can you
> try again from a clean checkout and then updating to issue295?
>
> Others, does it work for you?
>
> What happens if you take a clean checkout and just replace the configure file
> with the one Andrew provided? (You need to manually extract the archive, replace
> the configure file in the correct directory, which I think is "CoinUtils" or
> something like that, then create a new archive.)
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________
>

Emil, what does
$ hg identify
say? Are you 100% that the previous contents of lp/coin were deleted? Can you
try again from a clean checkout and then updating to issue295?

Others, does it work for you?

What happens if you take a clean checkout and just replace the configure file
with the one Andrew provided? (You need to manually extract the archive, replace
the configure file in the correct directory, which I think is "CoinUtils" or
something like that, then create a new archive.)

I'm still getting the same error:

In file included from lp/coin/include/coin/ClpMatrixBase.hpp:8,
                 from lp/coin/include/coin/ClpPackedMatrix.hpp:9,
                 from lp/coin/include/coin/ClpModel.hpp:17,
                 from lp/coin/include/coin/ClpSimplex.hpp:16,
                 from lp/coin/include/coin/OsiClpSolverInterface.hpp:11,
                 from landmarks/landmark_cost_assignment.cc:8:
lp/coin/include/coin/CoinFinite.hpp: In function ‘bool CoinFinite(double)’:
lp/coin/include/coin/CoinFinite.hpp:113: error: ‘finite’ was not
declared in this scope
make: *** [.obj/landmarks/landmark_cost_assignment.1.o] Error 1

which may have something to do with the following output, if you're
using the fix of checking for isfinite first:

checking whether isfinite is declared... nochecking whether finite is
declared... yes

so I guess configure can't figure out properly which of the functions to use?
On Thu, Nov 10, 2011 at 5:24 PM, Malte Helmert
<downward.issues@googlemail.com> wrote:
>
> Malte Helmert <malte.helmert@unibas.ch> added the comment:
>
> OK, I committed something to the issue branch and pushed it. So far, it's not
> yet merged back to default; I'd like to see it tested first. Can someone give
> this a whirl? Please follow these steps, paying special heed to the two cleanup
> steps:
>
> $ hg pull
> $ hg update issue295
> $ cd src/search
> $ make distclean
> $ rm -r lp/coin
> $ make USE_LP=1 all
>
> ----------
> status: chatting -> testing
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________
>

OK, I committed something to the issue branch and pushed it. So far, it's not
yet merged back to default; I'd like to see it tested first. Can someone give
this a whirl? Please follow these steps, paying special heed to the two cleanup
steps:

$ hg pull
$ hg update issue295
$ cd src/search
$ make distclean
$ rm -r lp/coin
$ make USE_LP=1 all

> PS. The other thing which might be useful here is that I have a lightweight C++
> abstraction layer to allow our planners to work with CLP, CPLEX or LPSolve.  In
> our experience CLP is fast if it works, so it's our default, but CPLEX is more
> robust.

Sounds very useful! However, for now, I'd prefer to keep things as is, since
only a very small and somewhat esoteric part of the code uses linear programming
(I almost never set USE_LP=1), and everything we add to our codebase comes with
a maintenance cost. When in doubt, I'd prefer to err on the side of not add more
code.

(If LP stuff should end up becoming a more prominent part of the planner, I'd
see things differently.)

PS. The other thing which might be useful here is that I have a lightweight C++
abstraction layer to allow our planners to work with CLP, CPLEX or LPSolve.  In
our experience CLP is fast if it works, so it's our default, but CPLEX is more
robust.

(In theory, Osi itself should allow CPLEX to be used silently in place of Clp,
but I found and reported several bugs that are still outstanding, so it wasn't
useful for our purposes.)

I tried the newer version, seems they've changed some files and the
header that the landmark code depends on is no longer there
(OsiClpSolverInterface.hpp). So upgrading would probably be more
trouble than it's worth.

On Thu, Nov 10, 2011 at 3:42 PM, Malte Helmert
<downward.issues@googlemail.com> wrote:
>
> Malte Helmert <malte.helmert@unibas.ch> added the comment:
>
> Thanks, Andrew! I suggest the following split of work:
>
> 1) I'll merge the necessary changes into our default branch (based on the Osi
> version we currently ship, since it doesn't look like there's much point in an
> upgrade).
>
> 2) Someone else reports this as a bug to the COIN-OR project.
>
> Any takers?
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________
>

I'll post the patch on the CoinUtils mailing list.

On your decision not to upgrade, that's what I'd have suggested.  On occasion,
when using it with COLIN, upgrades have led to CLP crashing unexpectedly, so I
tend to keep a known good version around and use that as far as possible.

Thanks, Andrew! I suggest the following split of work:

1) I'll merge the necessary changes into our default branch (based on the Osi
version we currently ship, since it doesn't look like there's much point in an
upgrade).

2) Someone else reports this as a bug to the COIN-OR project.

Any takers?

Yes, configure is derived from configure.ac , which can be equivalently patched
as follows:

--- configure.ac        2010-05-21 10:25:11.000000000 +0100
+++ configure.ac.patched        2011-11-10 14:07:44.000000000 +0000
@@ -79,7 +79,7 @@
 # Function finite #
 ###################
 MY_C_FINITE=
-AC_CHECK_DECL([finite],[MY_C_FINITE=finite],,[
+AC_CHECK_DECL([isfinite],[MY_C_FINITE=isfinite],,[
 #ifdef HAVE_CMATH
 # include <cmath>
 #else
@@ -102,7 +102,7 @@
 # endif
 #endif])
 if test -z "$MY_C_FINITE"; then
-  AC_CHECK_DECL([_finite],[MY_C_FINITE=_finite],,[
+  AC_CHECK_DECL([finite],[MY_C_FINITE=finite],,[
 #ifdef HAVE_CMATH
 # include <cmath>
 #else
@@ -125,7 +125,7 @@
 # endif
 #endif])
   if test -z "$MY_C_FINITE"; then
-    AC_CHECK_DECL([isfinite],[MY_C_FINITE=isfinite],,[
+    AC_CHECK_DECL([_finite],[MY_C_FINITE=_finite],,[
 #ifdef HAVE_CMATH
 # include <cmath>
 #else


The new OSI archive you mention still requires the same basic change (to check
in the order isfinite, finite, _finite), but applied to BuildTools/coin.m4 :

--- coin.m4     2011-09-03 21:07:59.000000000 +0100
+++ coin.m4.patched     2011-11-10 14:14:54.000000000 +0000
@@ -2294,7 +2294,7 @@
 AC_COIN_CHECK_CXX_CHEADER(ieeefp)
 
 COIN_C_FINITE=
-AC_CHECK_DECL([finite],[COIN_C_FINITE=finite],,[
+AC_CHECK_DECL([isfinite],[COIN_C_FINITE=isfinite],,[
 #ifdef HAVE_CMATH
 # include <cmath>
 #else
@@ -2317,7 +2317,7 @@
 # endif
 #endif])
 if test -z "$COIN_C_FINITE"; then
-  AC_CHECK_DECL([_finite],[COIN_C_FINITE=_finite],,[
+  AC_CHECK_DECL([finite],[COIN_C_FINITE=finite],,[
 #ifdef HAVE_CMATH
 # include <cmath>
 #else
@@ -2340,7 +2340,7 @@
 # endif
 #endif])
   if test -z "$COIN_C_FINITE"; then
-    AC_CHECK_DECL([isfinite],[COIN_C_FINITE=isfinite],,[
+    AC_CHECK_DECL([_finite],[COIN_C_FINITE=_finite],,[
 #ifdef HAVE_CMATH
 # include <cmath>
 #else

In either version, after applying the patch, run:

AUTOTOOLS_DIR=/usr BuildTools/run_autotools

It may complain about having the wrong version of autoconf/automake/libtool.  I
circumvented this by changing the version numbers mentioned in
BuildTools/run_autotools to match those on my system.  If the
isfinite-comes-first patch is to be submitted to COIN, this latter point doesn't
matter, as they deal with the unpleasant matter of running the autotools prior
to making the release archive.

> That's the default you get when you do a clean checkout.

Ah! :-) Maybe someone should look into this then, but it's not related to this
issue.

> Andrew's seems preferable since it doesn't require the user to edit
> any code. Note that the setup file has to change as well though.

In case it wasn't clear, the user should eventually not need to do anything --
we'll incorporate some solution into the main codebase. The way I see it, either
solution requires changing one file inside the COIN-LP archive; in one case it's
config_coinutils.h, in the other it's configure.

If I'm not mistaken, "configure" is ultimately a derived file generated by
autoconf, so maintaining changes to that through future updates of COIN-LP that
we might eventually want to integrate sounds more painful then maintaining the
header file change (since I understand the inner workings of that change
better). Am I missing something?

Speaking of future COIN-LP versions... we currently include the archive
Osi-0.103.0.tgz, which seems to be a bit outdated. The most recent version I
could find is 0.105.2 (from http://www.coin-or.org/download/source/Osi/).

Can someone test if the same source change is still needed for that version? If
not, we could look into replacing the code archive. If yes, we should tell them
about our fix in case they want to incorporate it in future releases.

That's the default you get when you do a clean checkout, I only added
the architecture specifications and changed enable-static to no.

On Thu, Nov 10, 2011 at 2:48 PM, Malte Helmert
<downward.issues@googlemail.com> wrote:
>
> Malte Helmert <malte.helmert@unibas.ch> added the comment:
>
>> ./configure CC="gcc -arch i386" CXX="g++ -arch i386" --prefix
> "$BASEDIR/coin" --enable-static=no --without-lapack || exit 1
>
> "--without-lapack" sets off a warning bell -- is LP solution performance decent
> with this option? Which matrix/LA package is used with this option?
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________
>

Andrew's seems preferable since it doesn't require the user to edit
any code. Note that the setup file has to change as well though.

On Thu, Nov 10, 2011 at 2:46 PM, Malte Helmert
<downward.issues@googlemail.com> wrote:
>
> Malte Helmert <malte.helmert@unibas.ch> added the comment:
>
> Andrew's solution changes the configure file while Emil's changes the code.
>
> Does anyone have an opinion/comment on which of the two solutions should be
> preferred?
>
> _______________________________________________________
> Fast Downward issue tracker <downward.issues@gmail.com>
> <http://issues.fast-downward.org/issue295>
> _______________________________________________________
>

> ./configure CC="gcc -arch i386" CXX="g++ -arch i386" --prefix
"$BASEDIR/coin" --enable-static=no --without-lapack || exit 1

"--without-lapack" sets off a warning bell -- is LP solution performance decent
with this option? Which matrix/LA package is used with this option?

Andrew's solution changes the configure file while Emil's changes the code.

Does anyone have an opinion/comment on which of the two solutions should be
preferred?

Adding Emil to nosy. (Of course, and as always, feel free to remove yourself
from the list again.)

Pasting from an email by Emil to the mailing list:

Had a bit of time to look at this today, here are the steps that work
for me to compile and link coin and fast-downward:

0) Set USE_LP in src/search/Makefile to 1, and comment out the line
that sets USE_LP=0 if the value of OS is osx.

1) Go to src/search/lp and replace the "configure" line in setup with
the following:

./configure CC="gcc -arch i386" CXX="g++ -arch i386" --prefix
"$BASEDIR/coin" --enable-static=no --without-lapack || exit 1

i.e. add CC = ... , CXX = ...., and set "enable-static" to no.

Then run setup.

2) In src/search/lp/coin/include/coin/config_coinutils.h, replace:

#define MY_C_FINITE finite
with
#define MY_C_FINITE isfinite

3) In src/search/Makefile, replace:

COIN_LINKOPT = -L $(COIN_ROOT)/lib -Wl,-Bstatic $(COIN_LIBS:%=-l %)
with
COIN_LINKOPT = -L$(COIN_ROOT)/lib $(COIN_LIBS:%=-l %)

(note that the space after -L is removed - not sure if this is an OS X
thing or depends on the version of gcc or what)

and replace

POSTLINKOPT_RELEASE += $(COIN_LINKOPT) -Wl,-Bdynamic
with
POSTLINKOPT_RELEASE += $(COIN_LINKOPT)

make in src/search should work after these steps. Hope this is useful
to somebody.

Attached is a replacement Osi-0.103.0/CoinUtils/configure .  I've swapped the
tests for isfinite and finite, so the former is checked for before the latter. 
As far as I understand, isfinite is always preferable, so I can't see a problem
with this.

I don't actually think so, since we would have to do this in the guts of COIN, 
which would mean that we can't reliably rebuild the thing.

Butchering into configure.ac some "if this is Darwin, just use isfinite" rule is 
probably the easiest way out.  Unfortunately, I don't understand this language 
well enough to do that myself (I don't understand what variables configure will 
have available to it when that rule is run --- it doesn't seem like UNAME is one 
of those variables).  If someone can enlighten me, I will put in said rule, test 
it, and deliver a patch when I'm confident it's working.

Wrestling with autoconf & co. is always messy. Could we work around this by
adding something to our code (in an appropriate #ifdef block) that defines a
"finite" method that forwards to "isfinite", or whatever the two symbol names are?

Andrew --- my autoconf fu is weak.  I see what is wrong in configure.ac --- OS X 
<math.h> does sorta define finite(), but it's clearly deprecated:

#if !defined( __STRICT_ANSI__) && !defined(_ANSI_SOURCE) && 
(!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))
extern int finite ( double );			/* Legacy API: please use C99 
isfinite() instead. */

extern double gamma ( double );			/* Legacy API: please use C99 
tgamma() instead. */

#if (!defined(_XOPEN_SOURCE) || defined(_DARWIN_C_SOURCE))

#if !defined(__cplusplus)
extern int matherr ( struct exception * );
#endif

Unfortunately, the definition seems to be picked up by configure:


MY_C_FINITE=
AC_CHECK_DECL([finite],[MY_C_FINITE=finite],,[
#ifdef HAVE_CMATH
# include <cmath>
#else
# ifdef HAVE_MATH_H
#  include <math.h>
# endif
#endif
#ifdef HAVE_CFLOAT
# include <cfloat>
#else
# ifdef HAVE_FLOAT_H
#  include <float.h>
# endif
#endif
#ifdef HAVE_CIEEEFP
# include <cieeefp>
#else
# ifdef HAVE_IEEEFP_H
#  include <ieeefp.h>
# endif
#endif])
if test -z "$MY_C_FINITE"; then
  AC_CHECK_DECL([_finite],[MY_C_FINITE=_finite],,[
#ifdef HAVE_CMATH
# include <cmath>
#else
# ifdef HAVE_MATH_H
#  include <math.h>
# endif
#endif
#ifdef HAVE_CFLOAT
# include <cfloat>
#else
# ifdef HAVE_FLOAT_H
#  include <float.h>
# endif
#endif
#ifdef HAVE_CIEEEFP
# include <cieeefp>
#else
# ifdef HAVE_IEEEFP_H
#  include <ieeefp.h>
# endif
#endif])
  if test -z "$MY_C_FINITE"; then
    AC_CHECK_DECL([isfinite],[MY_C_FINITE=isfinite],,[
#ifdef HAVE_CMATH
# include <cmath>
#else
# ifdef HAVE_MATH_H
#  include <math.h>
# endif
#endif
#ifdef HAVE_CFLOAT
# include <cfloat>
#else
# ifdef HAVE_FLOAT_H
#  include <float.h>
# endif
#endif
#ifdef HAVE_CIEEEFP
# include <cieeefp>
#else
# ifdef HAVE_IEEEFP_H
#  include <ieeefp.h>
# endif
#endif])
  fi
fi
if test -z "$MY_C_FINITE"; then
  AC_MSG_WARN(Cannot find C-function for checking Inf. Check will test whether 
the value is different from DBL_MAX)
else
  AC_DEFINE_UNQUOTED([MY_C_FINITE],[$MY_C_FINITE],
                     [Define to be the name of C-function for Inf check])
fi


Any idea how to override this?

OK, all of these look reasonably simple to fix.

There are some minor issues with the makefile, which I believe can be worked 
around (I'll post a patch file RSN), and there is the need for isfinite (see 
previous message about full COIN tree to fix).

Other than that, it seems like someone is calling for -lrt, which does not exist 
on Mac OS X.

> Would it be reasonable to replace the compressed tarball of COIN in the fast-
> downward repository with a full tree?  I'm not entirely sure how one might
> patch the tarball

If you want to work on this, feel free to expand it temporarily in your
repository (assuming you're also working with hg). I'll worry about how to
integrate it back once it works.

Would it be reasonable to replace the compressed tarball of COIN in the fast-
downward repository with a full tree?  I'm not entirely sure how one might patch 
the tarball....

It looks like the configure script for COIN is producing an incorrect
config_coinutils.h.  Edit the header file to read:

#define MY_C_FINITE isfinite

...instead, and try that.

(I'm interested to see how you get on, as it so happens I'm working with someone
who wants CLP on a mac to run our planners, too.)

Here's the quote from Emil about this (see issue277, msg1897):

================================================================================
By the way, COIN doesn't compile on OS X. I got it to compile once, but it 
involved lots and lots of hacks and changes that would be impossible to put in a
Makefile. Everything else should work normally though.
================================================================================

So there may be more problems lurking. (Have you tried "make -k" to see if there
are additional errors further on?)

Not sure I can help much with this, but let me know if I can. Regarding your
question in the mailing list: a possible configuration to evaluate this on could be

--search "astar(lmcount(lm_hm(m=1),admissible=true,optimal=true),mpd=true)"

That's one of the configurations from the ECAI 2008 paper by Emil, Silvia and me.

I find that I can build COIN itself, but the attempt to compile it into fast-
downward fails.  Here's the error:


g++ -Iext -g -m32 -Wall -W -Wno-sign-compare -Wno-deprecated -ansi -pedantic -
Werror -DSTATE_VAR_BYTES=1 -I lp/coin/include/coin -D USE_LP -D COIN_USE_CLP -O3 
-DNDEBUG -fomit-frame-pointer -c landmarks/landmark_cost_assignment.cc -o 
.obj/landmarks/landmark_cost_assignment.1.o
In file included from lp/coin/include/coin/ClpMatrixBase.hpp:8,
                 from lp/coin/include/coin/ClpPackedMatrix.hpp:9,
                 from lp/coin/include/coin/ClpModel.hpp:17,
                 from lp/coin/include/coin/ClpSimplex.hpp:16,
                 from lp/coin/include/coin/OsiClpSolverInterface.hpp:11,
                 from landmarks/landmark_cost_assignment.cc:8:
lp/coin/include/coin/CoinFinite.hpp: In function 'bool CoinFinite(double)':
lp/coin/include/coin/CoinFinite.hpp:113: error: 'finite' was not declared in 
this scope
make: *** [.obj/landmarks/landmark_cost_assignment.1.o] Error 1

Indeed, MY_C_FINITE seems to be defined to be "finite":

/* Define to be the name of C-function for Inf check */
#define MY_C_FINITE finite

and we have:

inline bool CoinFinite(double val)
{
#ifdef MY_C_FINITE
  //    return static_cast<bool>(MY_C_FINITE(val));
    return MY_C_FINITE(val)!=0;
#else
    return val != DBL_MAX && val != -DBL_MAX;
#endif
}

in CoinFinite.hpp

I look at the file architecture/i386/math.h on my laptop, and I see isfinite(x),
but not finite(x).