Examples and tools depend on internal APIs in shared library builds

[hoshiizumiya]

Description

Some example and tool targets currently depend on libtorrent internal APIs marked with TORRENT_EXTRA_EXPORT.

This becomes visible when building libtorrent as a shared library without TORRENT_EXPORT_EXTRA.

The currently identified targets are:

• examples/connection_tester
  • uses internal merkle_* helper functions from aux_/merkle.hpp
• tools/checking_benchmark
  • uses the internal stat_file() helper from aux_/path.hpp

When BUILD_SHARED_LIBS=ON, these internal symbols are not normally exported from torrent-rasterbar, so these targets fail to link unless TORRENT_EXPORT_EXTRA is enabled.

Expected behavior

Examples and tools should ideally not require libtorrent's internal DLL interface.

TORRENT_EXPORT_EXTRA can remain limited to test builds, while examples and tools either:

• avoid internal APIs,
• provide small local implementations where appropriate, or
• are temporarily excluded from shared-library builds until they are refactored.

Possible follow-up

For checking_benchmark, the internal filesystem helper may eventually be replaced with std::filesystem.

For connection_tester, the small Merkle helper functions could potentially be implemented locally instead of depending on libtorrent's internal Merkle helpers.

Impact

This does not affect normal users of the main torrent-rasterbar library.

The issue is limited to optional example/tool targets when building against the shared library. Static builds are not affected because the required implementation is linked directly into the executable.

This was discovered while feature-testing the libtorrent 2.1.1 update in vcpkg: microsoft/vcpkg#53354. You can download them and check the error in the Azure pipline artifacts checks page in the PR.

Related: #8721