Date: Wed, 27 Apr 2016 19:32:15 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 209110] textproc/luceneplusplus: Build problems with libc++ 3.8.0 Message-ID: <bug-209110-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209110 Bug ID: 209110 Summary: textproc/luceneplusplus: Build problems with libc++ 3.8.0 Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: arved@FreeBSD.org Reporter: dim@FreeBSD.org Assignee: arved@FreeBSD.org Flags: maintainer-feedback?(arved@FreeBSD.org) 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/l= ucene++-contrib_CXX_prefix.hxx:4: In file included from /wrkdirs/usr/ports/textproc/luceneplusplus/work/.build/src/contrib/cotire/l= ucene++-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 to= ol 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 proje= ct. 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/c= otire/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<>, a= nd 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 th= is 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209110-13>