$ poudriere jail -cj clang8 -v projects/clang800-import -m svn+https $ poudriere testport -j clang8 net/ceph13 [...] src/common/config.cc:1476:56: error: temporary of type 'boost::static_visitor<unsigned long>' has protected destructor *member = boost::apply_visitor(get_size_visitor<T>{}, val); ^ /usr/local/include/boost/variant/static_visitor.hpp:53:5: note: declared protected here ~static_visitor() = default; ^ src/common/config.cc:1482:56: error: temporary of type 'boost::static_visitor<long>' has protected destructor *member = boost::apply_visitor(get_size_visitor<T>{}, val); ^ /usr/local/include/boost/variant/static_visitor.hpp:53:5: note: declared protected here ~static_visitor() = default; ^ 2 errors generated. http://package18.nyi.freebsd.org/data/headamd64PR236062-default/2019-03-01_06h42m53s/logs/errors/ceph13-13.2.1.log
yeay, great, Hi Jan, I'm still trying to recover from al kinds of incompatible changes made by the Ceph team. Most painfull one atm: ld.lld and ld.bfd do not see eye2eye on versioning and versioning maps.. Is Clang 8 going to be introduced any time soon now? In HEAD? But then this looks more like a Boost error, if the dtor is protected?
(In reply to Willem Jan Withagen from comment #1) > ld.lld and ld.bfd do not see eye2eye on versioning and versioning maps.. Can't you mark the port as LLD_UNSAFE? Sorry if I forgot the details why ld.bfd isn't good enough. As for version maps it maybe an LLD regression, first noticed in bug 230602. > Is Clang 8 going to be introduced any time soon now? I hope. If FreeBSD 11.2 didn't get Clang/libc++ 6.0 in time you'd probably have more C++17 issues with Ceph by now. ;) > In HEAD? Yes. MFC to /stable is likely to require ~1 month of baking on /head. > But then this looks more like a Boost error, if the dtor is protected? Maybe but Boost 1.70 (bug 235956) is also affected, see https://ptpb.pw/kMXm
Reminder: Clang 8 was merged to 13.0-CURRENT in base r344779. Maintainers, expect pkg-fallout@ mail soon.
(In reply to Jan Beich from comment #2) It looks like my scanners trigger on mailware on https://ptpb.pw/kMXm. So can't check that one out. But ik looks like the boost code is intentional protected, and is intended to be overloaded with an explicit dtor that goes with the inherited type. Dirty shortcut is to make the dtor public. Code will compile, but will likely also leak memory.
(In reply to Jan Beich from comment #0) I tried and replaced the {} by (), thus converting to just a regular ctor, the error goes away. And the whole thing compiles on a very recent 13.0 with clang 8. If you want I can make a patch, but feel free to do yourself. Just let me know
(In reply to Jan Beich from comment #2) > > ld.lld and ld.bfd do not see eye2eye on versioning and versioning maps.. > > Can't you mark the port as LLD_UNSAFE? Sorry if I forgot the details > why ld.bfd isn't good enough. At first ld.bfd ran out table space or something while binding some of the programs... So I switched to LLVM ld I now switched to the binutils in ports: 2.32, and that ld does not have that problem. Not everything is fixed, but that could very well be me changing too much. After I reverted all, I hope things do compile again. > As for version maps it maybe an LLD regression, first noticed in bug 230602. It is rather hard to find any documentation explaining versioning in depth. Let alone that it does not help that binutils ld and LLVM ld really do not see things the same way. I got quite far, but now dynamic loading with dlopen() fail to find the versioned functions. But without good understanding it just is nothing more that factorial search in all the possible versions that could work (or mostly not)
(In reply to Willem Jan Withagen from comment #5) >f you want I can make a patch, but feel free to do yourself. Yes, please provide the patch.
Submitted a upgrde to a new Ceph release in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239958 Which should fix this issue as well.
Fixed with ports r4509257.