Bug 236209 - net/ceph13: fails to build with clang 8
Summary: net/ceph13: fails to build with clang 8
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kurt Jaeger
URL:
Keywords: needs-patch
Depends on:
Blocks: 236062
  Show dependency treegraph
 
Reported: 2019-03-04 12:59 UTC by Jan Beich
Modified: 2019-08-19 09:59 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (wjw)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2019-03-04 12:59:48 UTC
$ 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
Comment 1 Willem Jan Withagen 2019-03-04 14:05:44 UTC
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?
Comment 2 Jan Beich freebsd_committer 2019-03-04 16:51:12 UTC
(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
Comment 3 Jan Beich freebsd_committer 2019-03-04 23:31:12 UTC
Reminder: Clang 8 was merged to 13.0-CURRENT in base r344779. Maintainers, expect pkg-fallout@ mail soon.
Comment 4 Willem Jan Withagen 2019-03-05 21:13:06 UTC
(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.
Comment 5 Willem Jan Withagen 2019-03-09 11:32:06 UTC
(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
Comment 6 Willem Jan Withagen 2019-03-09 15:29:57 UTC
(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)
Comment 7 Walter Schwarzenfeld freebsd_triage 2019-08-14 11:05:43 UTC
(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.
Comment 8 Willem Jan Withagen 2019-08-18 23:44:40 UTC
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.
Comment 9 Walter Schwarzenfeld freebsd_triage 2019-08-19 09:59:54 UTC
Fixed with ports r4509257.