an efficient feature complete C++ bittorrent implementation

This PR suggests an implementation of the WebTorrent protocol inside libtorrent. With this add-on, libtorrent can be used to run hybrid peers seamlessly.

WebTorrent peers use the same application protocol as classic peers but with WebRTC Data Channels as underlying transport instead of uTP or TCP, allowing to run peers in web browsers. Due to the necessary connection signaling, WebTorrent peers require a specific WebSocket tracker to connect.

Since documentation seems to be lacking, I implemented the WebTorrent signaling protocol the best I could guess by looking at existing code. You can find useful information and the reference Javascript implementation here: https://github.com/webtorrent/webtorrent

The implementation requires two external dependencies added as submodules:

• libdatachannel, my lightweight WebRTC Data Channels implementation, which relies on my ad-hoc UDP Interactive Connectivity Establishment (ICE) library libjuice
• boost.JSON, a header-only JSON library for the tracker protocol

This PR does not add new external dependencies to libtorrent (it only requires OpenSSL or GnuTLS depending on the compilation option).

To test, you need a torrent file with at least one WebSocket tracker, for instance wss://tracker.openwebtorrent.com. You can find such a torrent file here: https://ageneau.org/upload/sintel.torrent You can also run a web browser peer on this page: https://webtorrent.io/

WebTorrent is a new implementation of the bittorrent protocol designed to work over WebRTC. This allows browsers to download torrents without plugins. However, due to the limitations of WebRTC it isn't possible to make the protocol compatible with bittorrent (or uTP).

If libtorrent supported WebTorrent it would be able to communicate with both the existing swarm as well as the browser swarm that is restricted to WebTorrent only.

When I seed a single 5GB file from an AWS server in Australia using the newest uTorrent version - to a single peer in Norway I get 2-3 megabyte/sec speed - which is pretty good compared to other UDP based transfer acceleration protocols. Flags in uTorrent on the peer side in Norway shows that uTP is used. The latency is about 350ms.

When I seed the same single file using libTorrent 1.1.0.0 I end up with approx 150-500 kbyte/sec. Flags in uTorrent on the peer side in Norway shows that uTP is used here as well. I am running vanilla settings for libTorrent - the only settings specified are seedmode = true and automanaged=false.

So it seems to be a uTP (UDP) performance issue with libtorrent?

I also saw a similar issue here where you are in the loop @arvidn : https://github.com/Tribler/tribler/issues/2620

What do you think?

libtorrent version (or branch): 1.1.0.0 platform/architecture: Win - x64 - static MT compiler and compiler version: VS2017 - toolset v.141

libtorrent version (or branch): 1.2.4

platform/architecture: x86_64 Linux Fedora 30

compiler and compiler version: gcc 9.2.1

When using qbittorrent 4.3.0-git with libtorrent 1.2.4, qbittorrent reports that none of the trackers work. Switching back to libtorrent 1.2.3 makes everything work just fine. Unfortunately qbittorrent does not produce any logs.

This adds a cibuildwheel workflow.

Features

• Builds and tests wheels in 28 flavors
• Can be run manually, with an option to upload to pypi
• ~~Will run automatically when a release is published, unconditionally uploads to pypi~~
• If a PR touches cibuildwheel infrastructure (cibuildwheel.yml or tools/cibuildwheel/**), we will test by building a representative sample of wheels (the full suite of wheels takes hours)
• Caches build artifacts, so re-runs are fast

Changes

• ~~The python project name is changed from python-libtorrent to just libtorrent. Closer to common practice in python, plus the name was available on pypi~~
• ~~Other changes to setup.py, following the principle that --config-mode=distutils should create a wheel-suitable build by default~~

Tests

I patched this (and other dependent build system changes) on the v1.2.14 and v2.0.4 tags. I uploaded the wheels to test-pypi:

• https://test.pypi.org/project/libtorrent/2.0.4.post3/
• https://test.pypi.org/project/libtorrent/1.2.14.post3/

Release procedures and notes

• @arvidn should create a pypi API token restricted to the "libtorrent" project, and add it as a github actions secret (PYPI_API_TOKEN)
• EDIT: also create an API token on test-pypi restricted to the separate "libtorrent" project there, and add it as a github actions secret TEST_PYPI_API_TOKEN
• I already registered the project on pypi (EDIT: and test-pypi), and invited @arvidn as an owner

Proposed release procedure:

• before you create a release, manually run the cibuildwheel workflow without publishing to pypi, to make sure everything builds
• If everything builds, run the workflow again and publish to pypi. ~~Or just create the release, and the workflow will publish automatically.~~

Release procedure caveats

NOTE: pypi uploads are immutable, and filenames cannot be reused even after files are deleted. Publish with care!!

• I already uploaded some files for libtorrent 2.0.4, then deleted them, not realizing those filenames can never be used again
  • If desired, this could be remedied by publishing a 2.0.4.1 release
• It's good practice to upload to https://test.pypi.org/ before uploading the "production" index at https://pypi.org/
• ~~But "libtorrent" at test-pypi is held by someone else, I believe by github user @mayli~~
• ~~I have contacted @mayli by email to transfer ownership of the test-pypi project~~ EDIT: mayli transferred ownership of the project, thanks!

Build Flavors

• cp37-cp37m-macosx_10_9_x86_64
• cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64
• cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64
• cp37-cp37m-musllinux_1_1_aarch64
• cp37-cp37m-musllinux_1_1_x86_64
• cp37-cp37m-win32
• cp37-cp37m-win_amd64
• cp38-cp38-macosx_10_9_x86_64
• cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64
• cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64
• cp38-cp38-musllinux_1_1_aarch64
• cp38-cp38-musllinux_1_1_x86_64
• cp38-cp38-win32
• cp38-cp38-win_amd64
• cp39-cp39-macosx_10_9_x86_64
• cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64
• cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64
• cp39-cp39-musllinux_1_1_aarch64
• cp39-cp39-musllinux_1_1_x86_64
• cp39-cp39-win32
• cp39-cp39-win_amd64
• cp310-cp310-macosx_10_9_x86_64
• cp310-cp310-manylinux_2_12_x86_64.manylinux2010_x86_64
• cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64
• cp310-cp310-musllinux_1_1_aarch64
• cp310-cp310-musllinux_1_1_x86_64
• cp310-cp310-win32
• cp310-cp310-win_amd64

Missing flavors

Flavors we'd like to build but can't

• macos arm64
  • the x86 macos runners can cross-compile, but I can't seem to make it work. We are invoking b2 architecture=arm address-model=64 which should be right, but there are still link errors about mixing x86_64 objects.
  • macos on x86_64 cannot run or emulate arm64 code, so these builds can't be tested until there are m1 mac runners
• macos universal2
  • b2 architecture=combined address-model=64 does not build this (should pick -arch x86_64 -arch arm64), even in boost 1.77.0. I tried cxxflags="-arch x86_64 -arch arm64", but the compiler says these flags are unused.
  • as above, these can't be tested until there are m1 mac runners. apparently mac on m1 can emulate x86_64, so universal binaries can be tested on a single runner, just not the runners we have
• ~~musllinux~~
  • ~~this is new, and cibuildwheel doesn't support it yet~~ EDIT: the latest cibuildwheel supports this!
• pypy
  • the python bindings don't build with this. I'll investigate

Other flavors

The build times already take hours, and the artifacts are large due to static linking, and pypi has finite hosting space. We should add flavors as requested, rather than building everything.

Python 3.6 will reach end of life in 2021-12, so I've preemptively removed it from the list to shorten build times. numpy has already done this in their most recent release

Future optimizations

The builds currently take hours on aarch64 and other emulated architectures. It would be nice to reduce this.

abi3

The biggest win would be to use abi3 which would let us produce one build per platform rather than building for every python version. However

• boost-python doesn't support abi3
• pybind11 (the main boost-python alternative) doesn't support abi3
• cibuildwheel is janky to use with abi3

Prebuild dependencies

• openssl and boost-python (in all python versions) are built from source every time. We could cache them somewhere. On linux, using actions/cache is difficult because the builds run in docker. The right approach is probably to build a custom docker image with prebuilt dependencies. This would especially cut down build times for aarch64 and other emulated architectures.

macos ccache

We build artifacts for a given platform sequentially in a single job, which lets us use ccache. On the Linux builds this works well today.

On mac, ccache reports 0% hit rates between builds for some reason. The only thing that changes is the python version. We should investigate this.

windows ccache equivalent

On Windows, there is no build caching. It would be nice to have. However the Windows builds already complete in ~40 minutes, so this is a smaller gain compared to others.

I checked. The library shows that there are peers, but it doesn't download anything. Most devices in the world do not have sparse mode. It's an obvious library bug.

libtorrent version (or branch):

qBitTorrent 4.3.1 LibTorrent 1.2.11.0

platform/architecture: Windows 10 64-bit

LibTorrent remains connected to peers and seeds even when stalled because connected clients do not have any more torrent chunks to send.

Please provide the following information

libtorrent version (or branch):

• 1.1.7
• 1.1.8
• 1.1.9

platform/architecture: Debian GNU/Linux 9, x86_64

compiler and compiler version:

gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

please describe what symptom you see, what you would expect to see instead and how to reproduce it.

This issue was originally posted on Reddit r/seedboxes. I am summarizing it here.

Deluge with the 1.1 branch of libtorrent (confirmed on .7, .8, and .9). Snatching torrents with autodl irssi on IPT and TL trackers.

After seeing the first Announce OK message (not related to the unregistered torrent issue in #315; workaround on that works fine), Deluge connects to only a small fraction of peers. Usually 2 to 5 over confirmed swarms of dozens (also 60+). Often, the uploader does not seem to be included in the swarm, or the uploader is not shown on Deluge because of the bug itself. Download and upload start and performance is (of course) terrible.

There are no other trackers that seem affected by the issue.

Pausing and resuming a torrent mid-race "fixes" the issue. From 2-5 peers, Deluge starts seeing the entire swarm. Most of which are finished already. Download goes to the max, upload is almost none as most of them are at 100% already.

A catch: the issue happens most of the times, but not all the times.

Downgrading to libtorrent 1.0.11.0 fixes the issue completely.

Somebody on Reddit suggested disabling UTP, but it does not solve the issue.

Please provide the following information

libtorrent version (or branch):

1.1.4

platform/architecture:

Debian Stretch x86-64 (Deluge)

compiler and compiler version:

Those used by the debian package / pre-compiled binaries for Ubuntu

please describe what symptom you see, what you would expect to see instead and how to reproduce it:

After postponing the update to 1.x as long as possible (0.16.18 on Debian Jessie works fine) but now Debian stable having reached 1.1.1 with the issue still in place, I hope it can be solved. The issue seems similar to https://github.com/arvidn/libtorrent/issues/219 but its resolution did not solve this one.

I'm trying to announce both my IPv4 and IPv6 addresses to trackers which resulted in me trying the following configurations:

• Binding to all addresses results in the client connecting to the tracker using the address it resolves to and not supplying either "ip" or "ipv6" parameters. If the tracker resolves to an v4 address, it only receives my IPv4 address and the same with IPv6.

• Binding to only IPv4 results in the same outcome except the tracker will obviously only see my IPv4 address.

• Binding to only IPv6 results in the client appending the "ipv6" parameter and the tracker receiving only the IPv6 address (two times).

• When binding to all addresses it's possible to use announce_ip which seems to work for both v4 and v6 according to NexusPHP. If one guesses the address family the tracker resolves to (or just forces it using /etc/hosts), it's possible to add the "missing" other address that way. This seems to be the only way to currently pass both v4 and v6 to it while also listening to both addresses.

To be sure the culprit are not these conditions: https://github.com/arvidn/libtorrent/pull/597/files#diff-19929347e18a6ff1fc37f09ec720306bR3147 I compiled 1.1.4 without them without any change.

A bit off-topic but I don't understand the reason for the latter condition. In a regular scenario I'd want to connect to as many peers as possible, private torrent or not. This obviously includes peers having only an IPv6 address (which at some point in the future will be the whole swarm).

Hey there,

I've been trying to get Deluge 1.3.12 + Libtorrent 1.0.7 to work in conjunction with an autodl filter and a watch folder from a private tracker. I've been running around in circles trying to figure out why if when a torrent is added before the tracker has registered it, the client will wait a full 30 minutes until the next announce to refresh.

I found the tracker_backoff setting and was hopeful that this would fix my problem; however, no amount of changing this value would do anything to solve my problem with unregistered torrents. The torrent gets added and if the torrent is not registered, the announce interval is set to 30 minutes.

I started wondering, perhaps a failure isn't being reported properly somehow. Sure enough, I altered the tracker URL to something bogus and suddenly the retry intervals were set according to the tracker_backoff setting ( 7, 15, 27, 45, 95, 127, 165 seconds, etc). This leads me to believe that somehow the error status on unregistered torrents isn't being recognized properly, even though the Announce Status reads: Error: (Unregistered Torrent) and as a result of being able to connect to the tracker, libtorrent decides to announce as if all is normal and set the next refresh to 30 minutes.

This may be a tracker specific issue; however, it's worth noting that the error state is read correctly when using AutoDL with rtorrent.

• refactor macros and create a common interface target
• Enquote non-list variables
• Specify project version directly in the build script instead of reading from version.hpp.
• correctly specify boost components and minimum required version.
• make all feature setup explicit, not automatic upon finding/not finding certain dependencies/components.
• get rid of ucm_flags.cmake and associated manual manipulation of CMAKE_CXX_* variable manipulation
• fix install-time warnings about CMP0007 and CMP0053
• use only target_* commands to propagate build and usage requirements, don't use any directory-scope commands.
• simplify feature selection
• make use of generator expressions to help better structure the main build script. The main build script is now roughly structured as follows:
  1. feature declaration/setup
  2. find required dependency packages
  3. main target configuration: add_library(...) followed by target_*(...) commands to configure its compile features, options, definitions, etc. We strive to call each target_*(...) command only once or as few times as possible, so that each logical property of the build (compile options, compile definitions, ...) can be contained in a single place, hopefully making things easier to find and thus the build script easier to maintain.
  4. optional build of bindings
  5. install configuration
  6. optional build of tools, examples, and tests

Pretty substantial overhaul. The focus was on modernizing and structuring it more logically and consistently.

Tested on Windows (x64-windows and x64-windows-static with vcpkg) and Ubuntu (dynamic build). Let's see if the CI complains...

Porting this to other branches is almost certainly non-trivial, but I'd be willing to help with that of course.

Feel free to ask about the reasoning for each of the changes.

EDIT: here is the old vs new dependency graph, as generated on Ubuntu 20.04 with CMake's --graphviz option, in a build with both tools and examples.

The biggest difference is that now the dependency on Boost components is correctly acknowledged (because we're explicitly linking its targets instead of "throwing in a bunch of include files").

The other big difference is that every target has a private dependency on the interface library libtorrent_common_cfg. This is so that targets of the libtorrent project can use some common options, without propagating to other upstream projects.

EDIT: current revised target dependency graphs after changes made with the feedback below with/without deprecated functions disabled, respectively.

libtorrent version (or branch): both v1.2.x and v2.0.x

platform/architecture: any

compiler and compiler version: any

When receiving some data from libtorrent using synchronous calls (for example, using some kind of torrent_handle getter), too long delays are noticed from time to time, regardless of either the current system load or the parameters of the affected torrent. It looks like either the synchronization code has some drawbacks, or it is implemented in a way that is unfriendly to the caller. Recently, we have tried to avoid synchronous calls as much as possible. Unfortunately, some of the mentioned data cannot be obtained asynchronously (for example, via torrent_status), so we still have to resort to synchronous way, which leads to GUI hangups.

I have been trying to understand an issue occuring on Fedora 36 and here are two comments from an openssl thread regarding some recent changes to crypto-policy

My post has all the links and info needs (patches/packages/potential causes/workarounds) https://github.com/openssl/openssl/issues/17662#issuecomment-1201245477

A reply about where the issue might be. https://github.com/openssl/openssl/issues/17662#issuecomment-1201293020

I have built on Fedora 36 and created this better back trace

Reading symbols from ./qbt-build/completed/qbittorrent-nox...
(gdb) run
Starting program: /root/qbt-build/completed/qbittorrent-nox
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Qt en_GB locale unrecognized, using default (en).
en_GB locale recognized, using translation.
Disabling HTTP communications proxy
HTTP communications proxy string:
terminate called after throwing an instance of 'boost::wrapexcept<boost::system::system_error>'
  what():  context: unknown option (digital envelope routines) [asio.ssl:50331817]

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, [email protected]=6, [email protected]=0) at pthread_kill.c:44
44            return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) bt
#0  __pthread_kill_implementation (threadid=<optimized out>, [email protected]=6, [email protected]=0) at pthread_kill.c:44
#1  0x00007f83a0e8dcb3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2  0x00007f83a0e3d9c6 in __GI_raise ([email protected]=6) at ../sysdeps/posix/raise.c:26
#3  0x00007f83a0e277f4 in __GI_abort () at abort.c:79
#4  0x00007f83a11a1b57 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#5  0x00007f83a11ad43c in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#6  0x00007f83a11ad4a7 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:58
#7  0x00007f83a11ad708 in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0x211cfc0 <typeinfo for boost::wrapexcept<boost::system::system_error>>, dest=0x4b23d0 <boost::wrapexcept<boost::system::system_error>::~wrapexcept()>)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:98
#8  0x00000000004b24da in boost::throw_exception<boost::system::system_error> (e=...) at /root/qbt-build/boost/boost/throw_exception.hpp:165
#9  0x00000000006a9485 in boost::asio::detail::do_throw_error (err=..., location=0x1991996 "context") at /root/qbt-build/boost/boost/asio/detail/impl/throw_error.ipp:38
#10 0x00000000006a944e in boost::asio::detail::throw_error (err=..., location=0x1991996 "context") at /root/qbt-build/boost/boost/asio/detail/throw_error.hpp:42
#11 0x0000000000787025 in boost::asio::ssl::context::context (this=0x2cf82f0, m=boost::asio::ssl::context_base::tls_client) at /root/qbt-build/boost/boost/asio/ssl/impl/context.ipp:364
#12 0x0000000000743670 in libtorrent::aux::session_impl::session_impl(boost::asio::io_context&, libtorrent::settings_pack const&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void>) (this=0x2cf7300, ioc=..., pack=..., disk_io_constructor=..., flags=...) at /root/qbt-build/libtorrent/src/session_impl.cpp:518
#13 0x00000000007087be in std::_Construct<libtorrent::aux::session_impl, std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(libtorrent::aux::session_impl*, std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) (__p=0x2cf7300) at /usr/include/c++/12/bits/stl_construct.h:119
#14 0x0000000000707ac0 in std::allocator_traits<std::allocator<void> >::construct<libtorrent::aux::session_impl, std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(std::allocator<void>&, libtorrent::aux::session_impl*, std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) (__p=0x2cf7300) at /usr/include/c++/12/bits/alloc_traits.h:635
#15 0x00000000007070dc in std::_Sp_counted_ptr_inplace<libtorrent::aux::session_impl, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(std::allocator<void>, std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) (this=0x2cf72f0, __a=...) at /usr/include/c++/12/bits/shared_ptr_base.h:604
#16 0x00000000007066ab in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<libtorrent::aux::session_impl, std::allocator<void>, std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(libtorrent::aux::session_impl*&, std::_Sp_alloc_shared_tag<std::allocator<void> >, std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) (this=0x7ffd9b1d88c8, [email protected]: 0x0, __a=...) at /usr/include/c++/12/bits/shared_ptr_base.h:971
#17 0x0000000000705e6c in std::__shared_ptr<libtorrent::aux::session_impl, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<void>, std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(std::_Sp_alloc_shared_tag<std::allocator<void> >, std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) (this=0x7ffd9b1d88c0, __tag=...) at /usr/include/c++/12/bits/shared_ptr_base.h:1712
#18 0x000000000070538d in std::shared_ptr<libtorrent::aux::session_impl>::shared_ptr<std::allocator<void>, std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(std::_Sp_alloc_shared_tag<std::allocator<void> >, std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) (this=0x7ffd9b1d88c0, __tag=...) at /usr/include/c++/12/bits/shared_ptr.h:464
#19 0x0000000000704807 in std::make_shared<libtorrent::aux::session_impl, std::reference_wrapper<boost::asio::io_context>, libtorrent::settings_pack, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&>(std::reference_wrapper<boost::asio::io_context>&&, libtorrent::settings_pack&&, std::function<std::unique_ptr<libtorrent::disk_interface, std::default_delete<libtorrent::disk_interface> > (boost::asio::io_context&, libtorrent::settings_interface const&, libtorrent::counters&)>&&, libtorrent::flags::bitfield_flag<unsigned char, libtorrent::session_flags_tag, void> const&) ()
    at /usr/include/c++/12/bits/shared_ptr.h:1010
#20 0x0000000000700fe8 in libtorrent::session::start (this=0x2cf6120, flags=..., params=..., ios=0x2cf6970) at /root/qbt-build/libtorrent/src/session.cpp:308
#21 0x000000000070170a in libtorrent::session::session (this=0x2cf6120, params=...) at /root/qbt-build/libtorrent/src/session.cpp:369
#22 0x000000000049a72f in BitTorrent::Session::initializeNativeSession (this=0x2cf1a00) at /root/qbt-build/qbittorrent/src/base/bittorrent/session.cpp:1103
#23 0x00000000004962d9 in BitTorrent::Session::Session (this=0x2cf1a00, parent=0x0) at /root/qbt-build/qbittorrent/src/base/bittorrent/session.cpp:457
#24 0x0000000000499f8a in BitTorrent::Session::initInstance () at /root/qbt-build/qbittorrent/src/base/bittorrent/session.cpp:1003
#25 0x000000000042f7ec in Application::exec (this=0x2cdd530, params=...) at /root/qbt-build/qbittorrent/src/app/application.cpp:634
#26 0x0000000000441e8c in main (argc=1, argv=0x7ffd9b1d9fa8) at /root/qbt-build/qbittorrent/src/app/main.cpp:312
(gdb)

I this is a libtorrent boost issue? or is the problem elsewhere?

Hi, I use libtorrent to download on a mounted google drive but when I resume a transfer, I always run out of disk space while it is checking the files. It seems like it copies the files locally. What settings could help me get around that? I'm using the python binding btw on a Ubuntu 18.04 Thank you

$BOOST_ROOT/b2.exe --toolset=gcc --layout=system cxxstd=20 variant=release threading=multi boost-link=static link=static runtime-link=static i2p=on dht=on boost-link=static fpic=on logging=off crypto=wolfssl deprecated-functions=on debug-symbols=off

Insert the header file #include <sys/stat.h> into include\libtorrent\stat.hpp could pass the compiling process.

But the "libtorrent.a" was broken because the stat macro (OpenSSL & WolfSSL) replaced the libtorrent::stat.

There is no such problem if crypto=built-in, it only existed on windows + MinGW.