mingw-distro
mingw-distro copied to clipboard
StephanTLavavej
Boost.Build needs to upstream a mingw-w64 patch for Boost.URL
The msys2/MINGW-packages project has a patch: https://github.com/msys2/MINGW-packages/blob/ca4e304acefff6f0e145a14c6419d3fd78bcfa2e/mingw-w64-boost/0012-allow-longer-path-on-mingw-w64.patch @AndrewSav brought this to my attention in https://github.com/StephanTLavavej/mingw-distro/issues/90#issuecomment-1874504412 and explained:
Without [this patch]
libboost_urlcompiling fails becauseartries to use a response file, due to long command line, and backslashes in the response file come out wrong way so the compilation fails.
This should be upstreamed to Boost.Build, which will allow it to handle Boost.URL on mingw-w64. The patch's content looks reasonable to me - it discards the pre-XP codepaths (Boost.Build really doesn't need to worry about someone attempting to build Boost on such incredibly ancient systems), then it allows toolsets targeting Windows (as this is execnt.cpp) that aren't imitating MSVC (i.e. that aren't defining _MSC_VER) to use longer command lines. This seems like a reasonable heuristic to distinguish "mingw-w64 via MSYS2" from "MSVC via cmd".
Alternatively, something in Boost.Build could be fixed to properly handle backslashes when using response files on MSYS2.
Alternatively, Boost.URL could be changed to avoid constructing such horrifically long command lines (in 1.84.0, it is the only Boost library to be affected by this problem).
Alternatively, Boost.URL could be changed to avoid constructing such horrifically long command lines
I think, this cannot be avoided really. It's just a list of object modules to link, and it has most of them...
Perhaps - but somehow, every other Boost library hasn't triggered this problem.
That's because of the it has most of them... part I believe. Others did not need this structure, but url for whatever reasons did. There is nothing inherently bad in structuring your source code over many files, if it's more convenient.
I suppose that's fair, so Boost.Build should be fixed - either the command-line length hack, or a true fix to avoid backslash escaping.
This is https://github.com/boostorg/url/issues/779 and https://github.com/bfgroup/b2/issues/352, which is fixed with https://github.com/bfgroup/b2/commit/2474be56b42e191bbc0706d46177703b24a7e7c3.
