Re: [boost] [config] Unable to locate boost main tree

Subject: Re: [boost] [config] Unable to locate boost main tree
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-03-08 12:22:21

>> I have an up to date copy of boost trunk on a new machine (u233)
>> running RHEL 6.0 kernel (Santiago).  You can see the results on the
>> trunk page under Ornl-intel-11.1.064.  For some reason the configure
>> script is having trouble locating the boost main tree.  I tried adding
>> --with-boost=... to no avail.  Is this a recent problem or perhaps
>> this is the first attempt under 6.0?
>
> I hard coded the path to my boost installation into the configure  script 
> and it ran.  Here's the results of configure with --enable-test  with 
> intel-11.1.064 on RHEL 6.0.
>
> the following macros need to be defined
> BOOST_HAS_PTHREAD_YIELD BOOST_NO_NUMERIC_LIMITS_LOWEST BOOST_NO_FENV_H 
> BOOST_NO_COMPLETE_VALUE_INITIALIZATION BOOST_NO_0X_HDR_TYPEINDEX

That's screwy somehow:

* BOOST_NO_0X_HDR_TYPEINDEX should be defined unconditionally in 
libstdcpp3.hpp
* BOOST_NO_NUMERIC_LIMITS_LOWEST should be defined for gcc prior to 4.5

Not sure but the others look wrong too.

> the following macros need to be undef'ed
> BOOST_NO_MS_INT64_NUMERIC_LIMITS BOOST_NO_EXTERN_TEMPLATE 
> BOOST_DEDUCED_TYPENAME BOOST_NO_0X_HDR_INITIALIZER_LIST
>
> Thanks.
>
> -- Noel
>
> [ here's gcc-4.4.4 on the same hardware / os ]
>
> the following macros need to be defined
> BOOST_HAS_VARIADIC_TMPL BOOST_HAS_PTHREAD_YIELD 
> BOOST_NO_NUMERIC_LIMITS_LOWEST BOOST_NO_FENV_H BOOST_NO_0X_HDR_TYPEINDEX
>
> the following macros need to be undef'ed
> BOOST_NO_VARIADIC_TEMPLATES BOOST_NO_SCOPED_ENUMS 
> BOOST_NO_EXTERN_TEMPLATE BOOST_NO_DELETED_FUNCTIONS 
> BOOST_NO_DEFAULTED_FUNCTIONS BOOST_DEDUCED_TYPENAME 
> BOOST_NO_0X_HDR_INITIALIZER_LIST

And that's totally screwy, to pick one example it says that 
BOOST_NO_EXTERN_TEMPLATE  need to be undefined, but it's only ever set for 
gcc-2.x!!

I don't understand why, but there's something completely wrong with those 
results...

OK double checked, it seems that recent Linux/GCC systems can't cope with 
that script - lots of spurious failures - I've regenerated the configure 
script with the latest autoconf version and hopefully this is fixed now. 
Can you try again?

Thanks!  John.