Created attachment 325030 [details] build.log app-text/libwps-0.2.7 fails with dev-libs/boost-1.50.0-r2: [...] checking for boost shared ptr... no configure: error: Could not find Boost implementation of shared_ptr [...] From config.log: [...] configure:15947: x86_64-pc-linux-gnu-g++ -c -O2 -pipe -march=native -fomit-frame-pointer -Wall -Wextra -pedantic -Weffc++ conftest.cpp >&5 conftest.cpp:23:34: fatal error: boost/shared_ptr.hpp: No such file or directory compilation terminated. configure:15947: $? = 1 [...] Works with dev-libs/boost-1.49.0-r1.
Created attachment 325032 [details] config.log
Created attachment 325034 [details] emerge --info # ln -s /usr/include/boost-1_50/boost /usr/include/boost worked around this for now.
configure: error: Could not find Boost implementation of shared_ptr !!! Please attach the following file when seeking support: !!! /var/tmp/portage/app-text/libwps-0.2.7/work/libwps-0.2.7/config.log
Created attachment 325502 [details, diff] libwps-boost-1.50 Simply adds the includes via append-cppflags due to eselect boost support being removed in ~arch
Any objections to applying Jory's patch?
I have a question about our boost handling, are we going to need to fck with every package to work with the new shiny boost approach. And if the answer is yes then NO I am against such per package alteration.
(In reply to comment #6) > I have a question about our boost handling, are we going to need to fck with > every package to work with the new shiny boost approach. > > And if the answer is yes then NO I am against such per package alteration. We had similar discussions already regarding FindKDEPimLibs.cmake (whether it should automagically add the boost dir to the include path just because boost headers are included in its headers and thereby its interface).
(In reply to comment #6) > I have a question about our boost handling, are we going to need to fck with > every package to work with the new shiny boost approach. For every package that needs boost but doesn't use boost.m4 from sys-devel/boost-m4 (if it's autotools-based) or FindBoost (if cmake-based). Which is not a very onerous requirement: packages that need anything with multiple slots or implementations (java, python, ruby, vala, etc.) already inherit special eclasses for that purpose that do the right thing automatically or with a standard one-line call for most packages, but may require more esoteric handling whose build systems use a non-standard approach for finding java or python. Now boost in gentoo will be getting the same treatment. It's a logical development. Back to the subject of the libwps ebuild: Jory's patch works, but it is not beautiful. Unless the situation is urgent, my suggestion is to properly patch libwps's configure.ac to use the standard macros from boost.m4, and submit that patch to libwps upstream.
I'd assume this is fixed with 1.51.0-r1 unless proven otherwise.
