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)
both ports build fine
(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?
(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.
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.
(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.
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@.
(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.
A commit references this bug:
Date: Thu Sep 21 19:59:36 UTC 2017
New revision: 450301
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):
Approved by: kde (rakuco)
Obtained from: upstream (cmake-3.9.3)
Thanks for feedback. Landed after formatting the patch (no code changes) to better conform to other kde@ backports.