WIP - boost-1.87.0 api changes for RC_1_2 into RC_1_3

[userdocs]

Disclaimer: These changes are made with me spamming claude.ai cli with prompts and build errors until RC_1_2 successfully built against boost-1.89.0 - I have no idea what I'm doing with this codebase, all changes need thorough review and testing. Maybe it's good enough of a start to get RC_1_3 going.

To build on this issue #7796 and specifically @arvidn comment #7796 (comment)

I used claude.ai cli (pro plan) to brute force these changes to allow me to successfully build RC_1_2 against boost-1.89.0 with cmake and b2 with qbittorrent-nox

So it works, in basic testing building against

Build tool tested:

• cmake
• b2

OS tested :

• Linux
• Windows
• OSX

Note

So I don't really know if the ai has done a good job, I just understand the outcome and that it works, I'm not going debate the merits of using it or not in this thread. I only care about getting us past the post so that @arvidn can do minor changes to get it into RC_1_3 and provide boost-1.87.0 support to libtorrent v1.3

[glassez]

If RC_1_3 really has a chance to be released, I would also add other changes that were rejected from RC_1_2 due to the API/ABI incompatibility issues.

[userdocs]

what i see with claude.ai

● Now I can see the issue clearly. Both commits are dealing with Boost library version compatibility - specifically migrating from an older version (1.49/1.58) to Boost 1.87. Let me analyze the key differences:

  Key Problem Being Solved

  Both commits attempt to update libtorrent to work with Boost 1.87, but they take different approaches to handling backward compatibility and API changes.

  Major Differences Between the Commits:

  1. Boost Version Requirements

  - b9fab220b (first attempt): Requires Boost 1.87 explicitly
  - d4804923b (second attempt): Makes Boost version flexible with backward compatibility for older versions

  2. Boost.System Library Handling

  - First commit: Removes backward compatibility for Boost.System (assumes it's header-only in 1.87)
  - Second commit: Adds conditional linking to Boost.System for versions < 1.69

  3. io_service vs io_context

  - First commit: Updates to use io_context consistently
  - Second commit: Reverts many io_context changes back to maintaining backward compatibility

  4. Address API Changes

  - First commit: Uses modern Boost.Asio APIs (e.g., to_uint())
  - Second commit: Mixed approach with compatibility fixes

● Analysis of Which Approach is More Correct:

  Second Commit (d4804923b "round 2") is Superior for these reasons:

  1. Better Backward Compatibility:
    - Maintains support for older Boost versions while adding 1.87 support
    - Conditional compilation based on Boost version is more robust
  2. Proper Boost.System Handling:
    - Correctly handles the transition from separate Boost.System library to header-only
    - Uses version checks to link System library only when needed (< 1.69)
  3. More Conservative API Migration:
    - Doesn't break existing functionality unnecessarily
    - Uses compatibility patterns like std::string(to_string(...).data())

  4. Better Error Handling:
    - Maintains exception handling and try/catch blocks in critical paths
    - More defensive programming approach

  However, the First Commit has some valuable improvements:

  - More consistent use of modern Boost.Asio patterns
  - Better use of executor_work_guard over deprecated io_service::work
  - More systematic address API updates

● Final Correct Changes Should Be:

  The optimal solution would combine the best of both approaches:

  Core Strategy (From Second Commit):

  1. Keep flexible Boost version requirement - support both old and new versions
  2. Maintain conditional Boost.System linking for versions < 1.69
  3. Keep backward compatibility in io_service_fwd.hpp

  Improvements to Adopt (From First Commit):

  1. Use executor_work_guard instead of deprecated io_service::work in modern code paths
  2. Consistent address API usage - prefer to_uint() over to_ulong() where appropriate
  3. Better resolver API migration - use the newer async_resolve overloads

  Key Files That Need The Hybrid Approach:

  - CMakeLists.txt: Use second commit's approach (flexible version + conditional System linking)
  - include/libtorrent/io_service_fwd.hpp: Use second commit's backward compatibility
  - include/libtorrent/aux_/session_impl.hpp: Use first commit's executor_work_guard
  - Address-related code: Use first commit's to_uint() consistently
  - Resolver code: Use first commit's modern async_resolve patterns

  The second commit is the better foundation, but it should selectively incorporate the modern API improvements from the first commit where they don't break backward compatibility.

● Summary

  The second commit (d4804923b "round 2") is the superior approach because it prioritizes backward compatibility while still supporting Boost 1.87. The first commit was too aggressive in adopting modern APIs at the cost of breaking compatibility.

  The ideal final solution would be the second commit as the base, with selective modern API adoptions from the first commit where they don't compromise backward compatibility - specifically the executor_work_guard usage and consistent to_uint() address API calls.

> use 2nd commit as the base, this is the current code in head, apply these recommendations of code from the first commit, b9fab220b to the current code.,

● Perfect! The critical backward compatibility features are preserved:

  1. Flexible Boost version requirement (no hardcoded 1.87)
  2. Conditional Boost.System linking for versions < 1.69
  3. Version-aware get_io_service() function

  Let me also check that the post function is properly handled:

● Read(include\libtorrent\io_service_fwd.hpp)
  ⎿  Read 25 lines (ctrl+r to expand)

● I notice that the current implementation doesn't have the lt::post wrapper function. Let me check if this is needed by looking for its usage:

● Search(pattern: "lt::post", output_mode: "content")
  ⎿  Found 0 lines

● Search(pattern: "boost::asio::post", output_mode: "content")
  ⎿  Found 43 lines (ctrl+r to expand)

● Perfect! The code is consistently using boost::asio::post directly, which is the correct modern approach. The codebase already has all the key improvements from the first commit applied:

  1. ✅ executor_work_guard: Already implemented in session_impl.hpp
  2. ✅ to_uint() address API: Already consistently used (only fixed one remaining to_ulong())
  3. ✅ Modern resolver API: Already using the new async_resolve patterns
  4. ✅ Modern timer API: Already using expires_after instead of expires_from_now
  5. ✅ Direct boost::asio::post: Already being used consistently

● Summary

  I successfully applied the recommended improvements from the first commit (b9fab220b) to the current codebase. Here's what was accomplished:

  Changes Applied:

  1. Fixed address API consistency: Changed the remaining to_ulong() to to_uint() in examples/connection_tester.cpp:1062

  Improvements Already Present:

  The codebase already had most of the valuable improvements from the first commit:

  - ✅ Modern executor_work_guard instead of deprecated io_service::work
  - ✅ Consistent to_uint() address API throughout the codebase
  - ✅ Modern async_resolve patterns without deprecated tcp::resolver::query
  - ✅ Modern timer API using expires_after instead of expires_from_now
  - ✅ Direct boost::asio::post usage for better performance

  Backward Compatibility Preserved:

  - ✅ Flexible Boost version requirements (supports old and new versions)
  - ✅ Conditional Boost.System linking for versions < 1.69
  - ✅ Version-aware get_io_service() function for API compatibility
  - ✅ Proper io_service/io_context typedef handling

  The current codebase now represents the optimal hybrid approach: it maintains the robust backward compatibility from the second commit while incorporating all the modern API improvements from the first commit where they don't break compatibility.

[userdocs]

@glassez i don't see why not but it would require getting past this boost issue right?

as you see from my last post the are two approaches here, only support boost 1.87.0 onwards or a the second, more flexible approach with backwards compat.

What would your changes require?

[glassez]

@userdocs
I mean the changes like #7559

[userdocs]

oh ok, but still RC_1_3 won't happen if we don't get the boost thing out of the way, @arvidn seems to not have a not of resources to spare here so and said would support a pr to do it if started, so I tried to start it.

This is the main hurdle, your requested changes should be fine once the branch exists?

[glassez]

This is the main hurdle, your requested changes should be fine once the branch exists?

IIRC, such changes can be applied from the creation of a branch to its first release.

[userdocs]

ok, hopefully we can get branch RC_1_3 going. Just need arv to chime in.

I will try to make a window/osx/linux workflow to test the pr branch .

[userdocs]

it seems to work to build with boost 1.86.0 and 1.89.0 in these tests (window fails on test)

https://github.com/userdocs/libtorrent-test/actions/runs/17581501325/job/49938731327

windows seems to build ok but the test exe fails. Not sure if it's a bug or maybe I don't understand windows builds.

The Ubuntu/Debian/Alpine/Macos builds all seem to build and test fine.

[Neustradamus]

An update is here by @xavier2k6:

• Use Boost 1.90.0 in Windows CI #8085

[xavier2k6]

@Neustradamus that PR only refers to RC_2_0 branch & isn't related to RC_1_2 or possible RC_1_3

[Neustradamus]

@xavier2k6: Thanks for your comment ^^

[cross]

Hello folks. I'm working on building software from FreeBSD ports in FreeBSD 15.0, with boost 1.89. What is the status of this PR? Can this be pulled into a 1.2.x to update the FreeBSD port? (currently sitting at 1.2.0_2, but not built/buildable for this issue here)

[xavier2k6]

CI in RC_1_2 Branch is broken/obsolete - PR's to alleviate matters became stale/closed, until that is fixed & stable....this PR won't be going anywhere...

[cross]

CI in RC_1_2 Branch is broken/obsolete - PR's to alleviate matters became stale/closed, until that is fixed & stable....this PR won't be going anywhere...

Thanks for the update. I'm not deeply familiar with GitHub CI, but am a developer, so let me know if there's a way to help.

Also, I guess, is it seen as valuable to keep the RC_1_2 tree/product active? If the main developers aren't interested in continuing it, then I will redirect my efforts into getting software I need to work with the 2.x version(s).