On 2-1-2018 17:13, Casey Bodley wrote: > > > On 01/01/2018 06:13 AM, Willem Jan Withagen wrote: >> On 31/12/2017 06:30, kefu chai wrote: >>> + ceph-devl >>> >>> On Wed, Dec 27, 2017 at 5:47 PM, Willem Jan Withagen >>> <wjw@xxxxxxxxxxx> wrote: >>>> Hi Kefu, >>>> >>>> In FreeBSD the portmanager of Boost wants to move to 1.66, and so >>>> normally >>>> they do a test run on all 33.000 ports to see what breaks. >>>> >>>> Now one of the things that breaks is Ceph, but i a way I do not >>>> understand... >>>> >>>> When linking ceph-common references to the /usr/local/lib/libboost_*.so >>>> files on Boost 1.65 are now replaced by -lBoost::thread invocations >>>> 1.66?? >>> >>> could you pastebin the error message? Boost::thread is the library >>> name. but I >>> don't think it can be passed to the linker. if you see this in the >>> command line, >>> something is wrong. >> >> It was the now traditional problem that a CMake upgrade does not run >> in sync with Boost upgrades. Took quite some runs, but now FreeBSD >> ports is at 12.2.2, and in preparation on the 1.66 Boost release it >> builds without Beast by execluding WITH_RADOSGW_BEAST_FRONTEND. >> >> Which will be switched back on once the 1.66 Beast works with v12.2.2. >> > > Okay, thanks. The rgw/beast changes for boost 1.66 are staged in > https://github.com/ceph/ceph/pull/19054. If there are delays in merging > that, I'm happy to pull them into a separate pr. And thanks for pointing > out that we'll need to backport those pieces for luminous. Right, If that/backporting is possible, then I can switch Beast back on for Luminous. And everything comes back into sync... The WITH_RADOSGW_BEAST_FRONTEND switch made it very convenient to let FreeBSD (prepare to) move to 1.66 without Ceph package building being disabled. And now everybody can do "its thing(tm)" without blocking dependencies. When I have a bit more time and #19054 is not merged by then, I'll take a stab at it. Thanx, --WjW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
