https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #35 from cqwrteur <unlvsur at live dot com> --- (In reply to Arsen Arsenović from comment #34) > (In reply to cqwrteur from comment #29) > > I don't know how you do that. It is impossible to upgrade glibc on any of my > > linux distributions. I tried ubuntu, arch linux. Neither of them allows me > > to upgrade glibc. After setting LD_LIBRARY_PATH, the kernel just panics. I > > guess you are using some sorts of the linux from scratch. > You did something wrong. Works fine here on Gentoo (and on Arch, when the > distributor updates it.. you just screwed the process up). > > (In reply to cqwrteur from comment #30) > > In fact it is so bad even i access a directory that contains libc for cross > > compiling. it crashes the system. > > > > [cqwrteur@DESKTOP-9B705LH x86_64-pc-linux-gnu]$ cd lib64 > > [cqwrteur@DESKTOP-9B705LH lib64]$ ls > > Floating point exception (core dumped) > > [cqwrteur@DESKTOP-9B705LH lib64]$ pwd > > /home/cqwrteur/toolchains/x86_64-w64-mingw32/x86_64-pc-linux-gnu/x86_64-pc- > > linux-gnu/lib64 > > [cqwrteur@DESKTOP-9B705LH lib64]$ > Unfortunately, I can't magically debug it. I certainly can't reproduce this > issue. > > Also, if that's the cross-compilers sysroot, would the target not be wrong? > > (In reply to cqwrteur from comment #31) > > The compiler builds on arch linux. runs on windows. produces binaries works > > on linux again. This is crossback compilation. > I see no reason why the sysroot would be irrelevant. There are two sysroots > involved here: the one containing MinGW stuff and the one containing > *-linux-gnu stuff. > > (In reply to cqwrteur from comment #32) > > https://github.com/trcrsired/toolchainbuildscripts/blob/ > > a9eb4dbddde50e8993abde895d2d70c3e36dba79/gccbuild/x86_64-w64-mingw32/x86_64- > > linux-gnu-crossback.sh#L202C209-L202C224 > > > > In fact the abi situation is so bad i have to ship windows GCC to build > > linux programs. > This is certainly not required. I have literally never done that, and I've > been producing binaries for all sorts of systems for a long time. > > I presume there's no ABI problem here until you prove otherwise. Compile > something with an old enough glibc and it'll work on everything that has > that version or newer. > > (In reply to cqwrteur from comment #33) > > https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html > > > > "If build and target are the same, but host is different, you are using a > > cross compiler to build a cross compiler that produces code for the machine > > you’re building on. This is rare, so there is no common way of describing > > it. There is a proposal to call this a crossback." > > > > Here build == target == x86_64-pc-linux-gnu but host == x86_64-w64-mingw32 > I see. I was not aware of the term. > > (In reply to cqwrteur from comment #31) > > > Why not? It has to pull libraries and headers from somewhere (note that I > > > do not know what "crossback" means). > > > > > > Note that there is desire to not predefine _GNU_SOURCE in C++ modes. See > > > the PRs Andrew referenced. > > > > > > https://github.com/trcrsired/gcc-releases/releases > > > > This one > > x86_64-pc-linux-gnu.tar.xz in 20240707-x86_64-w64-mingw32 > > > > The compiler builds on arch linux. runs on windows. produces binaries works > > on linux again. This is crossback compilation. > I won't run your binaries to check. > > I don't see why you need such a convoluted setup. What are you trying to > produce? If you want *-linux-gnu binaries for building *-linux-gnu > programs, I'd recommend one of a few options: > > 1) Just use the system distributed one, > 2) Build one with a prefix in some uncommon path like /opt/<something> and > link it against old glibc, > 3) Build glibc against the target system, if that system is known. Unless the "old enough glibc" won't be able to build latest GCC. Even glibc 2.25 (which is centos stucks with). Unless system distributed one is not an option for a lot of reasons. 1. Old enough glibc won't be able to build latest GCC 2. The machine itself is very slow to the point to unable to build gcc. For example Raspi. 3. The environment itself stucks for many reasons to the point of unusable. Like building GCC directly on windows natively. 4. Convience perspective. Testing MSVC, GCC and clang at the same time, testing GCC cross compilers. The best way is to build cross back compiler and use it on windows so that I can compile all the code on windows. mingw has nothing to do with things here. it is a cross compiler. It has nothing to do with sysroot in mingw. There is no need for sysroot at all.
