[MacPorts] #69698: boost @1.76: error: no member named 'result_of' in namespace 'boost'

MacPorts noreply at macports.org
Wed Apr 10 08:59:29 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:1 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/69698#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list