2

I've run into a seemingly impenetrable compile error related to Boost, which I've reduced to including a single boost header file. In compiling (with GCC 4.2 on Mac OS X 10.6.8) an empty file containing only this include:

#include "boost/date_time/posix_time/posix_time.hpp"

...generates these errors:

 In file included from ../../../Boost Libraries/Boost_1_55_0/boost/type_traits/has_left_shift.hpp:43,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/lexical_cast.hpp:165,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/string_parse_tree.hpp:13,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/period_parser.hpp:14,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/date_facet.hpp:23,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/gregorian/gregorian_io.hpp:16,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/gregorian/gregorian.hpp:31,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/time_formatters.hpp:12,
                 from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/posix_time.hpp:24,
                 from /Users/homedir/dev/TheProject/Mac/Xcode/../Source/feature/test.cpp:12:
../../../Boost Libraries/Boost_1_55_0/boost/type_traits/detail/has_binary_operator.hpp:155: error: expected unqualified-id before 'do'
In file included from ../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/posix_time.hpp:34,
                 from /Users/homedir/dev/TheProject/Mac/Xcode/../Source/feature/test.cpp:12:
../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/time_parsers.hpp:40: error: expected `}' at end of input
../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/time_parsers.hpp:40: error: expected unqualified-id at end of input
../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/time_parsers.hpp:40: error: expected `}' at end of input
../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/time_parsers.hpp:40: error: expected `}' at end of input
../../../Boost Libraries/Boost_1_55_0/boost/date_time/posix_time/time_parsers.hpp:40: error: expected `}' at end of input

These Boost libraries are being used as "headers only" -- unbuilt.

Any clues?

SMGreenfield
  • 1,680
  • 19
  • 35
  • I'm assuming you mean GCC as in the compiler collection, not the binary, but just in case: what command are you using to compile? Are you using `c++` or `g++`, or are you literally using `gcc`? – Corbin Jan 18 '14 at 22:50
  • XCode is generating: /Developer/use/bin/gcc-4.2 -x c++ (plus all the other options, paths, etc) – SMGreenfield Jan 18 '14 at 23:21
  • I suspect this library just doesn't like GCC 4.2. (It is after all quite old) – Billy ONeal Jan 19 '14 at 00:10
  • @BillyONeal -- According to the Boost Date Time Library docs: "The following compilers are known to fully support all aspects of the library: GCC 3.3, 4.x on Darwin"... – SMGreenfield Jan 19 '14 at 02:04

1 Answers1

1

The problem is in the file <AssertMacros.h>, which is somehow getting included.

It defines a macro named check (and another named require) which conflict with the function named check in "boost/type_traits/detail/has_binary_operator.hpp".

You can define __ASSERTMACROS__ to prevent this from happening.

FWIW, in Mac OS X 10.7 and later, Apple renamed these macros to __check etc, to forestall this problem.

Marshall Clow
  • 15,972
  • 2
  • 29
  • 45
  • --you are 100% correct. The "somehow" is that the 10.5 SDK's CarbonCore.framework includes Debugging.h, which in turn includes AssertMacros.h. And yes, defining __ASSERTMACROS__ solves the problem above. What are there other side-effects of doing that? – SMGreenfield Jan 20 '14 at 05:06
  • 1
    Defining `__ASSERTMACROS__` effectively prevents `` from being included, since that's what it uses as its' include guard. The side effect is that you can't use any of the macros defined in that file (which you probably aren't using anyway). – Marshall Clow Jan 20 '14 at 14:24