$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.