Bug 222207

Summary:

[cmake] net/ceph & net/ceph-devel: fails to build with boost 1.65

Product:

Ports & Packages

Reporter:

Jan Beich <jbeich>

Component:

Individual Port(s)

Assignee:

Jan Beich <jbeich>

Status:

Closed FIXED

Severity:

Affects Only Me

CC:

adridg, kde, wjw

Priority:

---

Keywords:

patch

Version:

Latest

Flags:

bugzilla: maintainer-feedback? (wjw)

Hardware:

Any

OS:

Any

Bug Depends on:

Bug Blocks:

220714, 224185

Attachments:

Description	Flags
Backport upstream commits	rakuco: maintainer-approval+

Description Jan Beich freebsd_committer

2017-09-11 02:48:15 UTC

See bug 220714 comment 27 and later.

/usr/bin/ld: cannot find -lBoost::thread
c++: error: linker command failed with exit code 1 (use -v to see invocation)

http://package18.nyi.freebsd.org/data/110amd64-default-PR220714/2017-09-10_10h55m57s/logs/errors/ceph-v12.2.0.log
http://package18.nyi.freebsd.org/data/110amd64-default-PR220714/2017-09-10_10h55m57s/logs/errors/ceph-devel-w.v2017.08.15.1.log

Comment 1 Jan Beich freebsd_committer

2017-09-11 02:59:10 UTC

After applying

https://github.com/Kitware/CMake/commit/fa114e7d708b
https://github.com/Kitware/CMake/commit/dbba53a5aae0

both ports build fine

http://sprunge.us/LPQU
http://sprunge.us/eMAa

Comment 2 Willem Jan Withagen 2017-09-11 09:49:02 UTC

(In reply to Jan Beich from comment #1)

Yes, this is usually a problem with (ceph) ports using Boost.
When Boost upgrade to a new version, Cmake needs to know about it.

During my development, sort of hacked aroound it until Cmake got the patches.
In the end this is also the better fix for Ceph as well.
Fetching the patches will not fix this, since it will need to be done with Cmake.

But I do not have insight in the plans of the Cmake maintainer.
Perhaps best to prod him?

Comment 3 Willem Jan Withagen 2017-09-12 16:28:49 UTC

(In reply to Willem Jan Withagen from comment #2)

I looked further into this, but as far as I can see is Boost 1.64 the version distributed in packages... So why does a build running 11.0-RELEASE try to fetch 1.65??? For me this is highly unexpected, and the errors are exactly the same as the ones I had when Boost went from 1.63 tot 1.64.
Upgrading Cmake then fixed that, but then Cmake needs to be at a revision that actually includes the indicated patches. I guess that would hold for most tools actually using Boost and not specifying the path for the library manually in the port.

I see that this blocks migration to Boost 1.65??
For which I very sorry.
Is there a way of fixing Cmake? Otherwise I have to start poking in the Cmake-files in Ceph. Which is doable, but not absolutely needed.

Comment 4 Jan Beich freebsd_committer

2017-09-19 21:33:45 UTC

Created attachment 186555 [details]
Backport upstream commits

(In reply to Willem Jan Withagen from comment #3)
> why do es a build running 11.0-RELEASE try to fetch 1.65???

The build log is from an exp-run. Once bug 220714 lands this package would be marked BROKEN unless you prefer pkg-fallout@ spam. AFAIK, there're no testing repos where you can install binary packages for pending port updates.

office@ doesn't seem to plan to maintain more than one version of boost as illustrated by how long it took to land bug 199601. I'm not part of office@ team, if not obvious.

Comment 5 Willem Jan Withagen 2017-09-19 21:57:16 UTC

(In reply to Jan Beich from comment #4)

Life could be simple, but then it never really is.

I'm not really into the version of Boost OR Cmake.
Just as long as a new Boost also updates the versioning in Cmake.

So every time Boost upgrades with the matching Cmake definitions, my ports will break. Which is bad, but I can't do much about it if the Cmake maintainer chooses not to upgrade.

I would consider your patch of rahter limited impact, but then that's me.
It is up to KDE@ to actually "do the right thing"

Other than harassing them over this ....
But I'd expect breakage for everything that mixes Boost and Cmake.

Comment 6 Adriaan de Groot freebsd_committer

2017-09-19 22:14:55 UTC

ok, so what we're seeing is that a new boost version comes out, and then the FindBoost cmake module needs to be updated to actually find that new version, and to find all the right dependencies. That's surprisingly fragile.

Since CMake 3.9 landed last week, updating this Find-module is a lot simpler, though. Thanks for pointing out the upstream commits.

I'm not sure if an exp-run is needed for module-updates .. that is something I'll discuss with my mentors and antoine@.

Comment 7 Raphael Kubo da Costa freebsd_committer

2017-09-20 10:39:23 UTC

(In reply to Adriaan de Groot from comment #6)
> I'm not sure if an exp-run is needed for module-updates .. that is something
> I'll discuss with my mentors and antoine@.

I don't think it is necessary in this case. Those two commits have already been backported to CMake's "release" branch, and I think that's enough to show everything should work.

More context:
* https://gitlab.kitware.com/cmake/cmake/merge_requests/1280
* https://gitlab.kitware.com/cmake/cmake/issues/17289

Comment 8 commit-hook freebsd_committer

2017-09-21 19:59:51 UTC

A commit references this bug:

Author: jbeich
Date: Thu Sep 21 19:59:36 UTC 2017
New revision: 450301
URL: https://svnweb.freebsd.org/changeset/ports/450301

Log:
  devel/cmake: backport boost 1.65.1 support

  CMake Warning at /usr/local/share/cmake/Modules/FindBoost.cmake:767 (message):
    Imported targets not available for Boost version 106501
  Call Stack (most recent call first):
    /usr/local/share/cmake/Modules/FindBoost.cmake:871 (_Boost_COMPONENT_DEPENDENCIES)
    /usr/local/share/cmake/Modules/FindBoost.cmake:1501 (_Boost_MISSING_DEPENDENCIES)
    CMakeLists.txt:558 (find_package)

  PR:		222207
  Approved by:	kde (rakuco)
  Obtained from:	upstream (cmake-3.9.3)

Changes:
  head/devel/cmake/Makefile
  head/devel/cmake/files/patch-git_ee1f8903

Comment 9 Jan Beich freebsd_committer

2017-09-21 20:01:29 UTC

Thanks for feedback. Landed after formatting the patch (no code changes) to better conform to other kde@ backports.