That is so false. glibc or many other libc go through the same process too. Some libcs like mlibc even requires libsupc++.
you first build gcc then build part of libc and then use that partial libc to build libgcc then go back to build entire libc then build libstdc++. There are no circular problem like you said. Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Liu Hao <[email protected]> Sent: Thursday, May 6, 2021 9:53:32 AM To: [email protected] <[email protected]>; Christer Solskogen <[email protected]> Subject: Re: [Mingw-w64-public] undefined reference to __udivmoddi4 with GCC 11.1.0 在 2021-05-06 18:01, Christer Solskogen 写道: > On 06.05.2021 06:14, sotrdg sotrdg wrote: >> BTW. Why do you still use GCC 11.1.0? It is too old. Now it is GCC 12.0.0. >> >> We have used GCC 11 for a year. It is too old. >> > > 11.1 was released 27th of April 2021. > > Don't feed the troll. This guy has been infamous for ignorant taunts like this. The first question that comes to the mind of every humble person who happens to encounter such issues is, 'why it has to be like that', instead of 'I think this and this; why it shouldn't have been like that'. As a process of cross compilation from scratch, winpthreads, as part of the CRT, has to be built before other libraries. This means when building winpthreads, a compiler that generates mingw-w64 target code is available without any libraries. Therefore winpthreads can't link against libgcc, otherwise it would effect an unresolvable circular dependency. x86 doesn't have hardware 64-bit division, which is conventionally provided by libgcc. As we can't link against libgcc, such routines have to be implemented in winpthreads itself. This is an unfortunate whack-a-mole game. -- Best regards, Liu Hao _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
