https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907
--- Comment #34 from Arsen Arsenović <arsen at gcc dot gnu.org> --- (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.
