[MacPorts] #69698: boost @1.76: error: no member named 'result_of' in namespace 'boost'
MacPorts
noreply at macports.org
Wed Apr 10 11:38:55 UTC 2024
#69698: boost @1.76: error: no member named 'result_of' in namespace 'boost'
----------------------+-----------------------
Reporter: Gandoon | Owner: michaelld
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.9.3
Resolution: | Keywords:
Port: boost |
----------------------+-----------------------
Comment (by Gandoon):
Replying to [comment:3 ryandesign]:
> Replying to [comment:2 Gandoon]:
> > That is somewhat odd though as both `libtorrent-rasterbar` and
`qBittorrent` depend on `boost181`:
>
> I am aware.
>
> Back before we had versioned boost ports (boost176, boost181, etc.) that
install their headers and libraries into nonstandard directories, we had
the boost port which installed its headers and libraries into the standard
directories. Gradually ports were migrated from the unversioned boost port
to the versioned ones. However, because the boost port installs into
standard directories, its headers and libraries might be found by build
systems even though we were intending them to use a different versioned
boost port's headers and libraries. The problem can be worked around by
using trace mode (unless you use macOS 13 or newer on Apple Silicon) or by
deactivating the boost port before building. The problem would go away if
the boost port were deleted.
I see.
Unfortunately I have `vtk @9.3.0_0+ffmpeg+python311+qt5+xdmf` installed
that depends on the unversioned `boost`, which is why it was installed in
the first place. As I mentioned, I tried by building a version of
`boost176` with Clang-14, a configuration known to have worked
historically for the mentioned for me broken ports. That solved the build
issue for `libtorrent-rasterbar` but it did still break `qBittorrent`. I
was unsure if it would have worked if I had deactivated the unversioned
`boost`, but as `qBittorrent` still failed I tried that route with the
currently active `boost181
@1.81.0_10+clang17+cmake_scripts+no_single+no_static+python312`. With the
unversioned `boost`deactivated in the end `qBittorrent` built as intended
even though `boost @1.81` was built with `+clang17`. I expected that maybe
I would have to revert to e.g. `+clang14` for `boost181` as well, but it
worked. I guess I found a workaround. However, I was, and still am a
little unsure if the current state will cause any trouble. As it hasn't
before I guess it will be fine. To be sure I did force a rebuild of
`libtorrent-rasterbar` with a deactivated unversioned `boost` and it seems
to build as intended. It remains to be seen if it the ports works as
intended.
This was somewhat unintuitive, but at least solvable. As it sounds as if
the unversioned `boost` should be deprecated, and that there are more than
one port that `boost` broke, maybe `libtorrent-rasterbar`, `qBittorrent`,
and any other port that shows this behaviour should have their respective
Portfiles report a conflict if an unversioned `boost` is installed and
active? And obviously, `vtk +xdmf` (and possibly others) needs to change
dependency to the versioned ports. I will have to check if I really need
the `vtk +xdmf` variant. If not, I could potentially get rid of the
unversioned `boost` and not run into this issue again.
Thank you for your input.
--
Ticket URL: <https://trac.macports.org/ticket/69698#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list