dev-libs/boost claims to support altivec instructions, but fails when trying to compile with them. Reproducible: Always Steps to Reproduce: 1. emerge dev-libs/boost (all recent versions appear to have the same problem) Actual Results: ERROR: dev-libs/boost-1.41.0-r3 failed: building boost failed Expected Results: Successful merge If I change CFLAGS to "-O2 -mcpu=G4 -mno-altivec -pipe" then dev-libs/boost compiles properly, but I would prefer to be able to take full advantage of my CPU's instruction set.
Created attachment 214243 [details] build log
Created attachment 214244 [details] emerge --info
Does it work with gcc-4.3?
Good call. I installed gcc-4.3.4 and now boost compiles with altivec enabled. So I guess this is one of those gcc-4.4 migration bugs, eh ?
@toolchain and ppc: According to upstream, the program below does not compile on gentoo with gcc-4.4, but compiles on gentoo with gcc-4.3 and compiles on any other distribution with gcc-4.4. Could you please investigate? ################################## #include<vector> int main() { return 0; } ################################## g++ -maltivec <source file>
it isnt a Gentoo issue -- the same build failure can be observed on Debian. gcc's altivec added more reserved keywords, so boost needs fixing. i'm not sure who said that test code fails on Gentoo because it doesnt.
I can confirm this: "powerpc-unknown-linux-gnu-g++" -x c++-header -O2 -mtune=G5 -mcpu=G5 -mabi=altivec -pipe -ggdb -fno-strict-aliasing -finline-functions -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/gcc-4.4/gentoorelease/../src/tr1/pch.hpp.gch" "libs/math/build/../src/tr1/pch.hpp" <output elided> ./boost/fusion/container/vector/detail/deref_impl.hpp:29: error: declaration does not declare anything ./boost/fusion/container/vector/detail/deref_impl.hpp:32: error: template argument 1 is invalid ./boost/fusion/container/vector/detail/deref_impl.hpp:33: error: ‘element’ in namespace ‘boost::mpl’ does not name a type ./boost/fusion/container/vector/detail/deref_impl.hpp:33: warning: ‘typedef’ was ignored in this declaration ./boost/fusion/container/vector/detail/deref_impl.hpp:37: error: type/value mismatch at argument 1 in template parameter list for ‘template<class T> struct boost::is_const’ ./boost/fusion/container/vector/detail/deref_impl.hpp:37: error: expected a type, got ‘vector’ ./boost/fusion/container/vector/detail/deref_impl.hpp:38: error: ‘element’ was not declared in this scope ./boost/fusion/container/vector/detail/deref_impl.hpp:38: error: template argument 1 is invalid ./boost/fusion/container/vector/detail/deref_impl.hpp:39: error: ‘element’ was not declared in this scope ./boost/fusion/container/vector/detail/deref_impl.hpp:39: error: template argument 1 is invalid ./boost/fusion/container/vector/detail/deref_impl.hpp:40: error: template argument 1 is invalid ./boost/fusion/container/vector/detail/deref_impl.hpp:40: error: template argument 2 is invalid ./boost/fusion/container/vector/detail/deref_impl.hpp:40: error: template argument 3 is invalid <output elided> ...failed updating 1 target... Adding -mno-altivec to the end of CFLAGS and CXXFLAGS makes the build complete. This should be done in the ebuild as a workaround until the underlying bug is fixed.
# gcc --version gcc (Gentoo 4.4.3 p1.0) 4.4.3
I just tried boost-1.42 and the same problem is still present, so I guess upstream has not fixed the gcc-4.4 compatibility issue yet.
This should be fixed in the latest boost-1.41.0-r3.
Adding -mno-altivec to the ebuild allows boost to compile, but is really suboptimal as far as fixing the problem goes.
(In reply to comment #11) > Adding -mno-altivec to the ebuild allows boost to compile, but is really > suboptimal as far as fixing the problem goes. > Sure, but there is nothing we can do about. That's upstream's problem and they know it.
