During the exp-run in bug 208158, it was found that textproc/luceneplusplus gives errors with libc++ 3.8.0 :
In file included from /wrkdirs/usr/ports/textproc/luceneplusplus/work/.build/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx:4:
In file included from /wrkdirs/usr/ports/textproc/luceneplusplus/work/.build/src/contrib/cotire/lucene++-contrib_CXX_prefix.cxx:8:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:138:
In file included from /usr/include/c++/v1/ios:215:
/usr/include/c++/v1/iosfwd:176:14: error: unknown type name 'mbstate_t'; did you mean '__mbstate_t'?
typedef fpos<mbstate_t> streampos;
/usr/include/sys/_types.h:113:3: note: '__mbstate_t' declared here
And many more similar errors. It turns out this is caused by cotire , a compilation speedup tool, which is used by lucene++. Among others, this tool scans the headers included by a project, and generates C++ files that can be precompiled, which should speed up the compilation of the rest of the project.
For example, the lucene++-contrib_CXX_prefix.cxx file is generated like so:
/* cotire.cmake 1.6.6 generated file */
/* /usr/work/share/dim/ports/textproc/luceneplusplus/work/.build/src/contrib/cotire/lucene++-contrib_CXX_prefix.cxx */
#pragma clang system_header
Unfortunately, the libc++ headers have now started using #include_next<>, and this wreaks havoc with the way cotire is generating its prefix files. For example, when the compiler encounters #include "/usr/include/c++/v1/wchar.h", that header will do #include_next <wchar.h> at some point, to get at the 'regular' wchar.h header in /usr/include. However, since cotire does not generate #include <wchar.h>, but an absolute path, the #include_next <> statement will now find the same header in /usr/include/c++/v1.
In short, cotire breaks #include_next<> processing, and I am unsure how to fix it properly. Maybe this could be submitted as an issue to the cotire author(s), since there are quite a lot of headers requiring this feature to work.
As a quick workaround, I disabled using cotire in the CMakeLists.txt files in the project, and then it compiles successfully. But I am unsure whether this is acceptable for the port maintainer.
IIRC Due previous build problems we already disable parts of cotire, so i think it is reasonable to disable cotire completely.
There is no patch to review, but if you feel confident, go ahead and commit a fix.
Otherwise it will take about a few days until i will have time to look into this issue.
I have disabled cotire. Thanks for reporting