Description Dimitry Andric 2016-04-27 19:32:15 UTC

During the exp-run in bug 208158, it was found that textproc/luceneplusplus gives errors with libc++ 3.8.0 [1]:

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
} __mbstate_t;
  ^

And many more similar errors.  It turns out this is caused by cotire [2], 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
#ifdef __cplusplus
#include "/usr/include/c++/v1/wctype.h"
#include "/usr/include/c++/v1/wchar.h"
#include "/usr/include/sys/types.h"
#include "/usr/include/c++/v1/sstream"
#include "/usr/local/include/boost/cstdint.hpp"
#include "/usr/local/include/boost/filesystem/fstream.hpp"
#include "/usr/local/include/boost/variant.hpp"
#include "/usr/local/include/boost/weak_ptr.hpp"
#include "/usr/local/include/boost/make_shared.hpp"
#include "/usr/local/include/boost/version.hpp"
#include "/usr/include/c++/v1/map"
#include "/usr/include/c++/v1/set"
#include "/usr/local/include/boost/unordered_map.hpp"
#include "/usr/local/include/boost/unordered_set.hpp"
#include "/usr/local/include/boost/thread/recursive_mutex.hpp"
#include "/usr/local/include/boost/enable_shared_from_this.hpp"
#include "/usr/local/include/boost/algorithm/string.hpp"
#endif

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.

[1] http://package18.nyi.freebsd.org/data/headamd64PR208158-default/2016-03-22_18h30m05s/logs/errors/lucene++-3.0.7.log
[2] https://github.com/sakra/cotire