ax_boost_base.m4 leads to dropping preset LDFLAGS variable

Metadata

Property	Value
Reported by	Bård Skaflestad (bard.skaflestad@sintef.no)
Reported at	Jul 3, 2012 09:31
Type	Bug Report
Version	2.0
Operating System	Unspecified / All
Last edited by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Last edited at	Jul 6, 2012 11:55
Closed by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Closed at	Jul 6, 2012 11:55
Closed in version	Unknown
Resolution	Fixed
Comment

Description

The AX_BOOST_BASE macro used by the build system contains a crucial misprint. As far as I can tell, the misprint was introduced in revision 6448 of dune-common/m4/ax_boost_base.m4 . Specifically, that revision renamed several variables including the variable used to preserve the LDFLAGS. Following 6448, any preset LDFLAGS are stored in

ax_boost_base_save_LDFLAGS_SAVED

but the rest of the macro, including the restoration of original preset LDFLAGS, references

ax_boost_base_save_LDFLAGS

without the additional "_SAVED" suffix.

This, effectively, means that if the user for any reason assigns LDFLAGS before calling a "configure" script that invokes AX_BOOST_BASE (e.g., the one in dune-istl), then the preset LDFLAGS will be lost.

I have attached a simple (simplistic?) fix relative to dune-common@6817 that removes the "_SAVED" suffix, but there's one caveat. I have not actually tested the result on the computer system where it actually matters in our case.

For reasons I have not been able to track down, processing the DUNE_BOOST_BASE (not AX_BOOST_BASE) macro with Autoconf 2.59 (the default version on Red Hat Enterprise Linux 5) leads to a race condition whereby the final BOOST_CPPFLAGS end up not including the "-DENABLE_BOOST" flag. This, naturally, leads to no end of grief when using the config.h file in software reliant on Boost (e.g., the ISTL tutorial "example.cc" file in dune-istl/dune/istl/tutorial/example.cc).

Anyway, I hope you'll consider the patch despite lack of testing.

Attachments

dune-common.patch