Boost 1.78 won't compile with MinGW GCC 10.3.0

[mamontov-cpp]

Make sure you completed the following tasks

• I searched the discussions
• I searched the closed and open issues
• I read the contribution guidelines

Environment and version details

• Operating System+version: Windows 10
• Compiler+version: GCC 10.3.0
• Shell: Batch
• B2 Version: Output of b2 -v and b2 --version

B2 Version 4.7. OS=NT.
  Copyright 1993-2002 Christopher Seiwald and Perforce Software, Inc.
  Copyright 2001 David Turner.
  Copyright 2001-2004 David Abrahams.
  Copyright 2002-2019 Rene Rivera.
  Copyright 2003-2015 Vladimir Prus.

  DEFAULTS: jobs = 6

• B2 Configuration: Output of b2 --debug-configuration in your project.

Place output of "b2 --debug-configuration" here.

Brief problem description

I'm not able to compile new Boost using MinGW

Steps to reproduce the issue

1. Compile new b2 via bootstrap.bat gcc
2. Copy executable b2.exe into boost root
3. Run b2 toolset=gcc --build-type=complete

Actual behavior summary

Observe - a error like boostorg/build#724 occurs, see log

https://pastebin.com/StBa7TS7

Run with the options: -d2 --debug-configuration: https://pastebin.com/bS2yknxS

Expected behavior summary

Boost should start building correctly.

[mamontov-cpp]

I've attempted to do a simple debug, and replaced targets.jam:596 start-building rule with following

local rule start-building ( main-target-instance )
{
	local non-recursive-targets ;
	ECHO "Source targets:" ;
	{
		local names ;
		for local t in $(.targets-being-built)
		{
			names += [ $(t).full-name ] ;
		}
		ECHO $(names) ;
	}
	for local t in $(.targets-being-built)
	{
		if  ( $(t).full-name != $(main-target-instance).full-name )
		{
			non-recursive-targets += $(t) ;
		}
	}
	.targets-being-built = $(non-recursive-targets) ;
    if $(main-target-instance) in $(.targets-being-built)
    {
        local names ;
        for local t in $(.targets-being-built) $(main-target-instance)
        {
            names += [ $(t).full-name ] ;
        }

        import errors ;
        errors.error "Recursion in main target references"
          : "the following target are being built currently:"
          : $(names) ;
    }
    .targets-being-built += $(main-target-instance) ;
	ECHO "Dest targets:" ;
	{
		local names ;
		for local t in $(.targets-being-built)
		{
			names += [ $(t).full-name ] ;
		}
		ECHO $(names) ;
	}
}

I've received following logs:

https://drive.google.com/file/d/16GK7k8McDFtwoxgpjtb3Zt6TCmcVJf29/view?usp=sharing

So, what I see is:

• The issue is with libs/log/build/stage-dependencies - it always goes after ./stage-proper target even for itself.
• The rule start-building runs always at this point (this is weird, but I don't know much about inner implementation of boost build)

Can someone explain to me, how the rule scanning is done there? Is there some filesystem sorting involved?
Also, my attempt at fixing recursion here failed - the build stops, I think there are some other checks.

[mamontov-cpp]

Bumped GCC version to latest 11.2.0, still unable to build.

[Kojoley]

Is your OS 32bit? I cannot reproduce on 64bit Windows 10 + MSYS2 MinGW GCC 10.3.0.
Where you've got the Boost sources, are they patched?

[mamontov-cpp]

Oh, I see. I used x86 version of gcc from MinGW. It seems to be working on x64 version of GCC.

[mamontov-cpp]

So, x86 gcc is not supported?

[Kojoley]

When it comes to supported/unsupported it's so vague for Boost. You'd better think in terms of testing regularity. I remember there were persistent MinGW workers on https://www.boost.org/development/tests/develop/developer/summary.html, but I don't see them for more than a year now.

The issue you are reporting should be in building scripts of some library. Try to find the offending library by selectively removing libraries (or building a subset). From the logs:

error: ./forward ./stage ./stage-proper libs/filesystem/build/stage libs/filesystem/build/stage-dependencies libs/log/build/stage libs/log/build/stage-dependencies libs/filesystem/build/stage

the candidates to have building script issues in this case. are log and filesystem.

[mamontov-cpp]

Yeah, I tried to use your approach and found that offending library was log (filesystem compiles just fine). I'll try to look more into it.

[Kojoley]

Yeah, I tried to use your approach and found that offending library was log (filesystem compiles just fine). I'll try to look more into it.

That's very generous of you, but I would suggest to report the issue to log maintainers before you run out of motivation :-)

[mamontov-cpp]

Yes, I think this issue may be closed, as this is not a build system issue.