Compiling a C++ program using the Boost TR1 headers gives a "No such file or directory" from within the boost header. Boost's TR1 library uses relative paths to delegate their TR1 wrapper headers to the standard headers in order to avoid self-inclusion (since they have the same name as the standard headers they expand). But for the Gentoo installation, the relative path is wrong. Reproducible: Always Steps to Reproduce: 1. Install the boost library using portage. 2. Create a C++ program like the following: // testtr1.cpp #include <memory> using std::tr1::shared_ptr; int main() { shared_ptr<int> p(new int(0)); } 3. Compile the program with G++, including the Boost TR1 header in the include path: g++ -I/usr/include/boost/tr1/tr1 -o testtr1 testtr1.cpp Actual Results: This compilation fails for me. The compilation error on my Gentoo box is: In file included from /usr/include/boost/tr1/tr1/memory:13, from testtr1.cpp:2: /usr/include/boost/tr1/detail/config_all.hpp:151:41: error: ../4.4.4/utility: No such file or directory Expected Results: On my Ubuntu Maverick system, this procedure compiles without error and produces a binary. On my system, I can kludge it to make it work by doing this (as root): cd /usr/lib64/gcc/x86_64-pc-linux-gnu/4.4.4/include && ln -s g++-v4/ 4.4.4 (Note that I'm on AMD64, but I don't think the error is limited to 64-bit.)
Does adding -DBOOST_TR1_GCC_INCLUDE_PATH=g++-v4 to the compile line as per http://www.boost.org/doc/libs/1_41_0/doc/html/boost_tr1/usage.html#boost_tr1.usage.include_style -> Important Note #2, help?
Yes, adding that does make the compilation succeed. (Although, this scenario doesn't match the symptoms described by that page; perhaps a bug should be filed against the Boost documentation.) I expect an autoconf macro can be used to make the compilation portable.
I am considering this mostly Boost issue itself, nothing we can do here. We are definitely would not deviate from upstream behaviour.
