#35490: libtorrent-rasterbar won't compile against new default boost variants ---------------------------------+------------------------------------------ Reporter: timbargen@… | Owner: devans@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: boost, libtorrent | Port: libtorrent-rasterbar ---------------------------------+------------------------------------------ Comment(by adfernandes@…): `boost` maintainer here. On a mac there are no huge changes between multithreaded and non-mt builds; all re-arrangement happens due to the code. (In other words, the ABI is always implicitly multithreaded and there is no code-generation that changes. The code may conditionally compile into something else, but this isn't like MSVC or GCC on Linux!) I can add the `mt` and `static` builds back to `boost`, but excessive compile-times are an often-reported bug. It appears to me that `libtorrent-rasterbar` is actually at fault here because it is assuming that `boost` libraries have a particular name. In fact, they don't. The `-mt` suffix is optional during build. Also, the python variant is not installed by default (and never has been!) and, last I checked, there is no way to make a port depend on a specific variant. My suggestion would be for the `libtorrent-rasterbar` Portfile to test specifically for the boost-python-mt library that it needs via `depends_lib lib:boost_python-mt` or whatever, but modified such that an error is printed such that it tells the user to rebuild boost with the appropriate python and single-threaded variants. -- Ticket URL: <https://trac.macports.org/ticket/35490#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS