Target recursion when building in Boost 1.78.0 via MinGW-w64 GCC x32 10.3.0/11.2.0 #170
Comments
|
Builds fine for me on MinGW-w64, both 32 and 64-bit binaries. Also, builds fine in CI. Note that the latest gcc version in this build is 8.1.0. I was able to reproduce this in MSYS2 build of MinGW-w64, but I don't think we ever supported that compiler. It was never tested, to my knowledge. I was able to work around this error by explicitly specifying I'm not sure why Boost.Build fails with the error with MSYS2 and not MinGW-w64. I suspect, this may have something to do with how Boost.Build deduces default |
|
Wow, workaround really worked for me. Thank you! |
B2 does not deduce Lines 22 to 72 in a3717b0 That's said I still don't understand how filesystem -> log -> filesystem cycles is formed ( |
To clarify, the "wrong" part was not because Boost.Log (or other libraries) did something wrong. The code you linked is perfectly valid, as far as I understand, and the issues were caused by a problem in Boost.Config. See boostorg/build#659 and boostorg/config#351. That should be fixed by now, though.
...and also why |
|
boostorg/build#659 has nothing to do with GCC, it is about MSVC toolset which IIRC does not support compilers located in Windows SDK. |
|
That problem was not specific to MSVC. |
Are you sure we are talking about the same thing? |
|
What about the original issue, it is rises from I don't understand why the cycle is detected when both log and filesystem is doing that, B2 should detect it even in example above. |
I was talking about the issues I linked in #170 (comment). If you look at the Boost.Config issue and the related PR, it is clear that the problem is not specific to MSVC.
No idea. But this should be an issue for Boost.Build. |
|
Meh, at times I think why I am caring about the problem that does not affecting me in any way, I debugged for you the issue in libraries you are maintaining and you show zero respect. Best wishes. |
|
Wow, didn't know, that this caused such discussion. Also, if address-model is not specified GCC x32 tries to build x64 builds. It fails at it, but that may be the issue, when platform-dependent checks are performed - what if something goes off there? |
Not sure where that's coming from. I certainly did not mean to offend you. I was merely pointing out that this is not the place to discuss Boost.Build issues. Boost.Build maintainers will not be monitoring this issue, so any debugging you've made would go unnoticed.
I think, the recursion error is a Boost.Build issue, not Boost.Config. At the very least, Boost.Build maintainers need to have a look at the problem and tell if there is something wrong with what the libraries are doing. The fact that it tries to build both 32 and 64-bit binaries is probably a separate issue, also in Boost.Build, IMO. Despite what @Kojoley says about |
@Kojoley Is it though? |
Project requirements applying to the libraries in the project is not an B2 issue, that's the whole point of the project requirements feature. Of course, an reliable dependency cycles diagnostic would be preferable, but it is a missing feature, not a bug.
For me
|
|
@Kojoley Ok, thank you. |
Moved from bfgroup/b2#112
When trying to compile the library on Windows 10 host with aforementioned compiler settings I stumbled upon the issue, that it generates recursion in targets. See the log part below (full logs are in original issue)
I've tried to debug it in original issue but it looks like the recursion is somehow related to target libs/log/build/stage libs/log/build/stage-dependencies . I don't have much experience with Jamfiles sadly - but it may be related to inner checks for log?
Note, that the issue is not occuring when using GCC x64.
The text was updated successfully, but these errors were encountered: