boost @1.76: error: no member named 'result_of' in namespace 'boost'

[Gandoon (Erik Hedlund)]

A few days ago I started having issues upgrading qBittorrent, at the time the revision updated libtorrent-rasterbar @2.0.10_1+python312 was still not available. As the latter became available and I get the same errors trying to build that, I now note that I seem to have either an issue with boost181 or with both libtorrent-rasterbar and qBittorrent. Consequently, I tried a forced rebuild of boost181 and I also tried various + options. I now have the following at my disposal:

port -v installed  boost181
The following ports are currently installed:
  boost181 @1.81.0_10+clang13+cmake_scripts+no_single+no_static+python312+regex_match_extra requested_variants='+clang13+cmake_scripts+regex_match_extra' platform='darwin 19' archs='x86_64' date='2024-04-05T11:17:14+0200'
  boost181 @1.81.0_10+clang17+cmake_scripts+no_single+no_static+python312 (active) requested_variants='+clang17+cmake_scripts' platform='darwin 19' archs='x86_64' date='2024-04-09T12:51:37+0200'
  boost181 @1.81.0_10+clang17+cmake_scripts+no_single+no_static+python312+regex_match_extra requested_variants='+clang17+cmake_scripts+regex_match_extra' platform='darwin 19' archs='x86_64' date='2024-04-04T13:23:17+0200'
  boost181 @1.81.0_10+clang17+mpich+no_single+no_static+python312 requested_variants='+clang17+mpich+python312' platform='darwin 19' archs='x86_64' date='2024-03-25T14:39:17+0100'

Neither of which results in a working build of libtorrent-rasterbar or qBittorrent. However, since every single failed build point is making a reference to boost, I have a strong feeling that this might indeed be mainly an issue with boost181 and not the dependent ports. I did see another user having an issue with building specifically libtorrent-rasterbar at #69569 that was due to a python mismatch. It would be interesting to hear if that user had any luck after rebuilding with +python312.

Searching for answers, another issue also popped up, as referenced in #68518 regarding C++11 or later. As can be seen here: ​https://en.cppreference.com/w/cpp/types/result_of, one possible culprit may be the deprecation of std::result_of as of C++20 (if I managed to decipher the references correctly) and that instead something along the lines of std::invoke_result should have been used instead. I am thus making a final test, rebuilding boost181 with +clang11 as I found some hints (​https://github.com/opencv/opencv/issues/21109) at std::result_of might be available if using pre-Clang 13, but as expected that did not help either. In the Portfile C++14 seems to be requested:

# ensure that compiler is using C++14 mode
configure.cxxflags-append -std=c++14

so, as it is before C++20, I did not expect this to be a problem.

I am not really sure what changed between the revisions, as I have libtorrent-rasterbar @2.0.10_0+python312 requested_variants='' platform='darwin 19' archs='x86_64' date='2024-04-04T14:31:31+0200' successfully built here.

An example of the multiple errors of the same type thrown for both ports, referencing boost:

In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/work/libtorrent-rasterbar-2.0.10/src/announce_entry.cpp:36:
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/work/libtorrent-rasterbar-2.0.10/include/libtorrent/announce_entry.hpp:43:
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_libtorrent-rasterbar/libtorrent-rasterbar/work/libtorrent-rasterbar-2.0.10/include/libtorrent/socket.hpp:56:
In file included from /opt/local/include/boost/asio/ip/tcp.hpp:19:
In file included from /opt/local/include/boost/asio/basic_socket_acceptor.hpp:19:
In file included from /opt/local/include/boost/asio/any_io_executor.hpp:22:
In file included from /opt/local/include/boost/asio/execution.hpp:18:
In file included from /opt/local/include/boost/asio/execution/allocator.hpp:19:
/opt/local/include/boost/asio/detail/type_traits.hpp:89:7: error: no member named 'result_of' in namespace 'boost'; did you mean 'std::result_of'?
using boost::result_of;
      ^~~~~~~~~~~~~~~~
      std::result_of
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/type_traits:2527:34: note: 'std::result_of' declared here
template <class _Callable> class result_of;
                                 ^

[Gandoon (Erik Hedlund)]

Failed build of libtorrent-rasterbar

[Gandoon (Erik Hedlund)]

Failed build of qBittorrent

[ryandesign (Ryan Carsten Schmidt)]

You are likely right that this is caused by you using a newer compiler that is capable of C++20. Note however that your error comes from the boost port @1.76, not the boost181 port. Everything using boost should be using the separate versioned boost ports, but for some reason we still have the unversioned boost port at an old version. It would be nice if we could get rid of that, since its mere presence can cause other port builds to fail.

[Gandoon (Erik Hedlund)]

Replying to ryandesign:

You are likely right that this is caused by you using a newer compiler that is capable of C++20. Note however that your error comes from the boost port @1.76, not the boost181 port. Everything using boost should be using the separate versioned boost ports, but for some reason we still have the unversioned boost port at an old version. It would be nice if we could get rid of that, since its mere presence can cause other port builds to fail.

That is somewhat odd though as both libtorrent-rasterbar and qBittorrent depend on boost181:

# port -v deps libtorrent-rasterbar
Full Name: libtorrent-rasterbar @2.0.10_1+python312
  Build Dependencies:   path:bin/cmake:cmake
  Library Dependencies: path:lib/libssl.dylib:openssl, port:python312, port:boost181

# port -v deps qBittorrent
Full Name: qBittorrent @4.6.4_0+gui+webui
Build Dependencies:   path:bin/cmake:cmake, port:pkgconfig, port:clang-16, path:libexec/qt6/lib/QtUiTools.framework/QtUiTools:qt6-qttools, port:boost181
Library Dependencies: port:libtorrent-rasterbar, path:lib/libssl.dylib:openssl, port:zlib, path:libexec/qt6/lib/QtCore.framework/Versions/A/QtCore:qt6-qtbase,
                      path:libexec/qt6/translations/qt_ar.qm:qt6-qttranslations, path:libexec/qt6/lib/QtSvg.framework/Versions/A/QtSvg:qt6-qtsvg

I guess the port could depend on boost181 @1.81.0_10 while the code itself references an unversioned boost @1.76. I see that boost indeed depends on boost176, so that could potentially have something to do with the situation. However, I did also rebuild that one as well on the off chance that it did make an impact. I now have the following:

# port -v installed boost176
The following ports are currently installed:
  boost176 @1.76.0_10+clang14+no_single+no_static+python311 requested_variants='+clang14' platform='darwin 19' archs='x86_64' date='2023-12-20T12:36:44+0100'
  boost176 @1.76.0_10+clang17+cmake_scripts+no_single+no_static+python312+regex_match_extra (active) requested_variants='+clang17+cmake_scripts+regex_match_extra' platform='darwin 19' archs='x86_64' date='2024-04-04T12:33:15+0200'

and I have tried both variants to no avail. I guess I could build a version with an "older" Clang and +python312 and see what happens, but I do not hold very high hopes.

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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.

[Gandoon (Erik Hedlund)]

Replying to ryandesign:

Replying to 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 boostdeactivated 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.

[Gandoon (Erik Hedlund)]

Two quick notes:

As there recently was made available an updated qBittorrent @4.6.5_0+gui, I tried again and I got the same error as before with the unversioned boost active. A deactivation of this let qBittorrent build without problems.

In addition, it seems as if my vtk @9.3.0_0+ffmpeg+python311+qt5+xdmf does not really care if the unversioned boost is active or not, at least not during a rev-upgrade despite that it lists port:boost as a dependency. Thus I assume that any linking is working as it should, presumably against my installed boost176 @1.76.0_10+clang14+cmake_scripts+no_single+no_static+python312. I assume that the next time vtk is updated (which seems due), especially if the library dependency on port:boost is still there, I will see what happens. I expect a complaint about dependencies not being met during build, but as the library is there and seemingly linked to, not having boost there won't have any implications in real life. As far as I can see, the port just soft-links select /opt/local/lib/libboost* instances to the boost176 installation anyway. I am guessing that it may be the presence of libraries and includes in /opt/local/lib and /opt/local/include/boost/ in the top-level directories that throws qBittorrent builds off. It expects boost181 but looks in the mentioned locations, finding boost176 content instead of /opt/local/libexec/boost/1.81/. Anyway, this issue seem to be a minor inconvenience more than anything.