I think we really need to relax the version requirements of glibc since version 2.34. I cannot use the upstream glibc due to the potential new and versioned symbols from glibc itself. Glibc2.38 is just too new tbh. Majority of linux distributions do not support glibc 2.38. Ubuntu 22.04 which is i guess the most of people are using is still using glibc 2.35 libstdc++ built with latest glibc would introduce import symbols like arc4random@GLIBC_2.36 __isoc23_strtoull@GLIBC_2.38 I have checked arc4random implementation in glibc. It does not do anything meaningful in terms of performance but just a wrapper of /dev/random. glibc only introduces the symbol since 2.36. I don't see why libstdc++ needs this and in fact it can break abi silently since passing arc4random as a device now has different behaviors across libstdc++ versions https://github.com/gcc-mirror/gcc/blob/abf3964711f05b6858d9775c3595ec2b45483e14/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc#L189 This is another thing which is useless for gcc and libstdc++ since libstdc++ won't use 0b 0B in scanf/printf. https://github.com/bminor/glibc/blob/4b2a1b602fc1ade0de85084feb328203be3147c9/include/features.h#L481 while glibc does not break the abi until 2.34. I suggest libstdc++ to use glibc below 2.34 functions.
Created attachment 58652 [details] dependency
The dependency is because you built with the newer version of glibc. If you build on an glibc there is no dependency. So you need to build with/against the oldest version you support. This is not a gcc issue but rather it is a build issue you have.
Note while glibc is backwards compatibility, it is not forward compatible. So if you build against the newest version of glibc, it will always use the newest symbols and that is by design.
(In reply to Andrew Pinski from comment #3) > Note while glibc is backwards compatibility, it is not forward compatible. > So if you build against the newest version of glibc, it will always use the > newest symbols and that is by design. I am pretty sure this is a bug in glibc. https://sourceware.org/bugzilla/show_bug.cgi?id=31974 #include <features.h> #include <stdio.h> int main() { const char *input = "42 Alice"; int number; int result = sscanf(input, "%d", &number); printf("Parsed number: %d\n", number); } This will always generate __isoc23_sscanf for g++ no matter what standard it is while for C it only generates __isoc23_sscanf when user passes -std=c23. Considering C++ does not even support 0B 0b for sscanf yet. It is perfectly reasonable to say it is a bug in glibc. However, libstdc++ should get rid of arc4random dependency.
(In reply to Andrew Pinski from comment #3) > Note while glibc is backwards compatibility, it is not forward compatible. > So if you build against the newest version of glibc, it will always use the > newest symbols and that is by design. The problem is that this will just break GCC build in the future. Many people are stuck with old versions of GCC and can't upgrade due to small issues like this. Please fix it by avoid using arc4random in libstdc++ for glibc. thank you
There is NO fix inside gcc/libstdc++. THe only fix is your build of GCC (which includes the target libraries) needs to be build against the oldest version of glibc you support. This is something which GCC cannot control. THIS IS HOW linking and backwards compatibility works.
Created attachment 58654 [details] patch
this is the patch. avoid using it thank you
(In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of glibc you support. This is > something which GCC cannot control. > THIS IS HOW linking and backwards compatibility works. That is a bad idea. I do not want to use old glibc. It will break in the future just like i cannot link against glibc 2.25 any more.
(In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of glibc you support. This is > something which GCC cannot control. > THIS IS HOW linking and backwards compatibility works. You gnu guys should stop being ignorant on issues like this. Or everyone will finally move to LLVM.
(In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of glibc you support. This is > something which GCC cannot control. > THIS IS HOW linking and backwards compatibility works. Try to create a gcc cross compiler 15 for glibc 2.25 for me. You cannot even do that. So what's the excuse?
(In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of glibc you support. This is > something which GCC cannot control. > THIS IS HOW linking and backwards compatibility works. Also if you don't think this is a bug. Explain this to me. Why C++ will use __isoc23_sscanf but C does not? #include <features.h> #include <stdio.h> int main() { const char *input = "42 Alice"; int number; int result = sscanf(input, "%d", &number); printf("Parsed number: %d\n", number); } g++ -S hello.cc -std=c++11 g++ -S hello.cc -std=c++14 g++ -S hello.cc -std=c++17 g++ -S hello.cc -std=c++20 g++ -S hello.cc -std=c++23 Why they all use __isoc23_sscanf in the latest glibc 2.40. If we compile it with gcc gcc -S hello.c -std=c11 gcc -S hello.c -std=c14 gcc -S hello.c -std=c18 gcc -S hello.c -std=c23 Only C23 uses __isoc23_sscanf. It does not make any sense tbh.
(In reply to cqwrteur from comment #12) > (In reply to Andrew Pinski from comment #6) > > There is NO fix inside gcc/libstdc++. > > THe only fix is your build of GCC (which includes the target libraries) > > needs to be build against the oldest version of glibc you support. This is > > something which GCC cannot control. > > THIS IS HOW linking and backwards compatibility works. > > Also if you don't think this is a bug. Explain this to me. Why C++ will use > __isoc23_sscanf but C does not? > > #include <features.h> > #include <stdio.h> > > int main() { > const char *input = "42 Alice"; > int number; > > int result = sscanf(input, "%d", &number); > > printf("Parsed number: %d\n", number); > > } > > g++ -S hello.cc -std=c++11 > g++ -S hello.cc -std=c++14 > g++ -S hello.cc -std=c++17 > g++ -S hello.cc -std=c++20 > g++ -S hello.cc -std=c++23 > > Why they all use __isoc23_sscanf in the latest glibc 2.40. > > If we compile it with gcc > > gcc -S hello.c -std=c11 > gcc -S hello.c -std=c14 > gcc -S hello.c -std=c18 > gcc -S hello.c -std=c23 > Only C23 uses __isoc23_sscanf. > > It does not make any sense tbh. C++98 uses scanf. every other C++ standard else uses __isoc23_sscanf. Only C23 uses __isoc23_sscanf while every other C standard, including c18 uses __isoc99_sscanf. I am using the same GCC 15 toolchain. Why? This is just a bug. Nothing more.
The patch is broken. Why treat glibc special here. Anyways you can use a sysroot from say Ubuntu 1804 or centos 5 to build your cross compiler and you don't need to rebuild glibc.
(In reply to cqwrteur from comment #12) > (In reply to Andrew Pinski from comment #6) > > There is NO fix inside gcc/libstdc++. > > THe only fix is your build of GCC (which includes the target libraries) > > needs to be build against the oldest version of glibc you support. This is > > something which GCC cannot control. > > THIS IS HOW linking and backwards compatibility works. > > Also if you don't think this is a bug. Explain this to me. Why C++ will use > __isoc23_sscanf but C does not? cc1plus defines _GNU_SOURCE which enables _ISOC2X_SOURCE in glibc features.h. downgrading libraries at runtime is _never_ supported. just downgrade the build sysroot, as I told you already. this is indeed not a bug, in any component. LLVM will not fix it either.
(In reply to cqwrteur from comment #10) > (In reply to Andrew Pinski from comment #6) > > There is NO fix inside gcc/libstdc++. > > THe only fix is your build of GCC (which includes the target libraries) > > needs to be build against the oldest version of glibc you support. This is > > something which GCC cannot control. > > THIS IS HOW linking and backwards compatibility works. > > You gnu guys should stop being ignorant on issues like this. Or everyone > will finally move to LLVM. You run into the same issue there too. Also you have been told a few times to stop with the insults.
(In reply to Arsen Arsenović from comment #15) > (In reply to cqwrteur from comment #12) > > (In reply to Andrew Pinski from comment #6) > > > There is NO fix inside gcc/libstdc++. > > > THe only fix is your build of GCC (which includes the target libraries) > > > needs to be build against the oldest version of glibc you support. This is > > > something which GCC cannot control. > > > THIS IS HOW linking and backwards compatibility works. > > > > Also if you don't think this is a bug. Explain this to me. Why C++ will use > > __isoc23_sscanf but C does not? > > cc1plus defines _GNU_SOURCE which enables _ISOC2X_SOURCE in glibc features.h. > > downgrading libraries at runtime is _never_ supported. just downgrade the > build sysroot, as I told you already. > > this is indeed not a bug, in any component. LLVM will not fix it either. Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C.
(In reply to Andrew Pinski from comment #16) > (In reply to cqwrteur from comment #10) > > (In reply to Andrew Pinski from comment #6) > > > There is NO fix inside gcc/libstdc++. > > > THe only fix is your build of GCC (which includes the target libraries) > > > needs to be build against the oldest version of glibc you support. This is > > > something which GCC cannot control. > > > THIS IS HOW linking and backwards compatibility works. > > > > You gnu guys should stop being ignorant on issues like this. Or everyone > > will finally move to LLVM. > > You run into the same issue there too. > > Also you have been told a few times to stop with the insults. Let's be real. You use upper case with insults here. I always say "please" "thank you" etc here. You are ragging at me for no reason today.
.
(In reply to cqwrteur from comment #17) > Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C. "it"? presuming you mean glibc, because _GNU_SOURCES enables all features, including the C2X specific ones. note that not enabling those would not fix downgrading being broken.
(In reply to Arsen Arsenović from comment #20) > (In reply to cqwrteur from comment #17) > > Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C. > > "it"? presuming you mean glibc, because _GNU_SOURCES enables all features, > including the C2X specific ones. > > note that not enabling those would not fix downgrading being broken. Then why is it not the case for C++98 or C18?
(In reply to Arsen Arsenović from comment #20) > (In reply to cqwrteur from comment #17) > > Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C. > > "it"? presuming you mean glibc, because _GNU_SOURCES enables all features, > including the C2X specific ones. > > note that not enabling those would not fix downgrading being broken. 2b is not even a feature for C++ standard. So glibc is wrong here right. Don't be mad about me. I don't see how this makes sense when you have different standard options doing completely different things for no good reason.
The c++ frontend has defined _GNU_Source since at least 2001.
(In reply to Andrew Pinski from comment #23) > The c++ frontend has defined _GNU_Source since at least 2001. Then why C++ by default uses a C standard feature that hasn't yet been added into C++ standard? This makes 0 sense.
_GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. The other issue is not a gcc issue but a build issue with not using a sysroot.
> The c++ frontend has defined _GNU_Source since at least 2001. You are de facto, breaking abi without any good reason. You break cross-compiling for linux distribution for even the last year. Glibc 2.34 (which was just 3 years ago) removed -lpthread dependency. I would accept glibc2.34 as a base. Then what about this __isoc99scanf that behaves differently under different C and C++ standard. How is this code even linkable? It easily becomes ODR violations. https://news.ycombinator.com/item?id=32471624 The problem is that unlike libstdc++, glibc is not upgradable. Don't make any excuse tbh. If people are not happy with it, fix it. If you give a reason for breaking abi for a good reason i would accept that, but you don't you just break abi for no reason. In this case, it is more like a bug for a C standard feature where C++ standard does not support, at least not yet. (In reply to Andrew Pinski from comment #25) > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. > > > The other issue is not a gcc issue but a build issue with not using a > sysroot. Except no matter i try with sysroot i does not really work out. Plus i am building crossback compiler. It should not even care about sysroot.
(In reply to cqwrteur from comment #26) > > The c++ frontend has defined _GNU_Source since at least 2001. > > You are de facto, breaking abi without any good reason. You break > cross-compiling for linux distribution for even the last year. Glibc 2.34 > (which was just 3 years ago) removed -lpthread dependency. I would accept > glibc2.34 as a base. Then what about this __isoc99scanf that behaves > differently under different C and C++ standard. How is this code even > linkable? It easily becomes ODR violations. It does not become an ODR violation. Functions behave different in different languages (such as C99 vs. C23 vs. C++11). This is not unusual. > https://news.ycombinator.com/item?id=32471624 > > The problem is that unlike libstdc++, glibc is not upgradable. This is false. I upgraded glibc a few days ago. > Don't make any excuse tbh. If people are not happy with it, fix it. If you give a > reason for breaking abi for a good reason i would accept that, but you don't > you just break abi for no reason. In this case, it is more like a bug for a > C standard feature where C++ standard does not support, at least not yet. No ABI was broken. > (In reply to Andrew Pinski from comment #25) > > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. > > > > > > The other issue is not a gcc issue but a build issue with not using a > > sysroot. > Except no matter i try with sysroot i does not really work out. Plus i am > building crossback compiler. It should not even care about sysroot. 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.
(In reply to Arsen Arsenović from comment #28) > (In reply to cqwrteur from comment #26) > > > The c++ frontend has defined _GNU_Source since at least 2001. > > > > You are de facto, breaking abi without any good reason. You break > > cross-compiling for linux distribution for even the last year. Glibc 2.34 > > (which was just 3 years ago) removed -lpthread dependency. I would accept > > glibc2.34 as a base. Then what about this __isoc99scanf that behaves > > differently under different C and C++ standard. How is this code even > > linkable? It easily becomes ODR violations. > > It does not become an ODR violation. Functions behave different in > different languages (such as C99 vs. C23 vs. C++11). This is not unusual. > > > https://news.ycombinator.com/item?id=32471624 > > > > The problem is that unlike libstdc++, glibc is not upgradable. > > This is false. I upgraded glibc a few days ago. > > > Don't make any excuse tbh. If people are not happy with it, fix it. If you give a > > reason for breaking abi for a good reason i would accept that, but you don't > > you just break abi for no reason. In this case, it is more like a bug for a > > C standard feature where C++ standard does not support, at least not yet. > > No ABI was broken. > > > (In reply to Andrew Pinski from comment #25) > > > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. > > > > > > > > > The other issue is not a gcc issue but a build issue with not using a > > > sysroot. > > Except no matter i try with sysroot i does not really work out. Plus i am > > building crossback compiler. It should not even care about sysroot. > > 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. 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.
(In reply to cqwrteur from comment #29) > (In reply to Arsen Arsenović from comment #28) > > (In reply to cqwrteur from comment #26) > > > > The c++ frontend has defined _GNU_Source since at least 2001. > > > > > > You are de facto, breaking abi without any good reason. You break > > > cross-compiling for linux distribution for even the last year. Glibc 2.34 > > > (which was just 3 years ago) removed -lpthread dependency. I would accept > > > glibc2.34 as a base. Then what about this __isoc99scanf that behaves > > > differently under different C and C++ standard. How is this code even > > > linkable? It easily becomes ODR violations. > > > > It does not become an ODR violation. Functions behave different in > > different languages (such as C99 vs. C23 vs. C++11). This is not unusual. > > > > > https://news.ycombinator.com/item?id=32471624 > > > > > > The problem is that unlike libstdc++, glibc is not upgradable. > > > > This is false. I upgraded glibc a few days ago. > > > > > Don't make any excuse tbh. If people are not happy with it, fix it. If you give a > > > reason for breaking abi for a good reason i would accept that, but you don't > > > you just break abi for no reason. In this case, it is more like a bug for a > > > C standard feature where C++ standard does not support, at least not yet. > > > > No ABI was broken. > > > > > (In reply to Andrew Pinski from comment #25) > > > > _GNU_SOURCE issue is recorded as pr 69350 and pr 11196 and maybe others. > > > > > > > > > > > > The other issue is not a gcc issue but a build issue with not using a > > > > sysroot. > > > Except no matter i try with sysroot i does not really work out. Plus i am > > > building crossback compiler. It should not even care about sysroot. > > > > 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. > > 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. 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]$
> 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.
(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. https://github.com/trcrsired/toolchainbuildscripts/blob/a9eb4dbddde50e8993abde895d2d70c3e36dba79/gccbuild/x86_64-w64-mingw32/x86_64-linux-gnu-crossback.sh#L49 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.
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
(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.
(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.
Also, it is a waste of energy and time to build the same compiler on different machines over and over again instead of just building one, packaging it and distributed it among many machines. Plus Cloud servers has storage usages quotes to the point of unable to do so.
(In reply to cqwrteur from comment #35) > Unless the "old enough glibc" won't be able to build latest GCC. Even glibc > 2.25 (which is centos stucks with). File a bug or write a patch. I'm not sure how you'd expect libraries to be forwards compatible - this is not magic. > 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. MINGW is required to build Windows programs, AFAIK (note that I've never built a Windows program..), at least due to the headers. This implies that the headers (and probably libraries) need to be in the sysroot of the to-Windows cross-compiler. This does not seem avoidable. (In reply to cqwrteur from comment #36) > Also, it is a waste of energy and time to build the same compiler on > different machines over and over again instead of just building one, > packaging it and distributed it among many machines. Plus Cloud servers has > storage usages quotes to the point of unable to do so. I agree - that's why I build binary packages of my Gentoo system. There is at least one other approach that I suggested (building once with an old glibc in some odd prefix).
> > 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. > MINGW is required to build Windows programs, AFAIK (note that I've never > built a Windows program..), at least due to the headers. This implies that > the headers (and probably libraries) need to be in the sysroot of the > to-Windows cross-compiler. This does not seem avoidable. I don't think you understand what you are talking about. The crossback compiler itself does not need to contain any sysroot and headers for mingw-w64. It only needs to contain linux headers and libs. https://github.com/trcrsired/gcc-releases/releases Go and download the compiler itself and try it with wine.
. This discussion now belongs in gcc-help@ rather than bugzilla since there is no GCC bug here.
I ran into exact the same trouble of C23 missing symbols on old systems. In my case it is a custom build (with tailored source) of libfreeimage which has some calls to `sscanf` pulling the unwanted symbol references (to `__isoc23_sscanf@GLIBC_2.38`) into the library. As said, the root cause is PR 11196. However, for this specific case `-U_GNU_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200809L` can just work for me, because all sites using the function are known exhaustively. The (un)interesting part is how to figure out the concrete feature sets need to be used. In fact, the workaround here follows the fix in https://sourceware.org/bugzilla/show_bug.cgi?id=21326. However, despite that bug is marked fixed, it actually misses `__USE_ISOC95` so names like `::fwide` will not be properly declared. That's why `_ISOC99_SOURCE` is needed here. Similarly, `_POSIX_C_SOURCE` is needed for `uselocale`. Such options should work as per platform ABI and the semantics of `_XXX_SOURCE`, in spite of the fact of unsupported status by GCC. The mismatch of runtime library and headers looks scary, but still feasible for compatibility purpose, working like dual-ABI libstdc++ in some degrees. That said, it requires the knowledge of the way to use symbols in the client code. Use at ones' own risks.
(In reply to frankhb1989 from comment #41) > I ran into exact the same trouble of C23 missing symbols on old systems. In > my case it is a custom build (with tailored source) of libfreeimage which > has some calls to `sscanf` pulling the unwanted symbol references (to > `__isoc23_sscanf@GLIBC_2.38`) into the library That is not a glibc issue but rather you are thinking glibc will be forwards compatible; glibc is not and never can be; this is true for almost all OS out there (Mac OS has a similar issue though they provide sysroots with all needed headers/libraries so it is slightly easier to handle rather than you need to go out and find one). It is definitely backwards compatiable. If you want to build a program that runs on older systems you 100% need to use the earliest version of glibc to link (and use headers from) against rather than the newest version.
(In reply to Andrew Pinski from comment #42) > (In reply to frankhb1989 from comment #41) > > I ran into exact the same trouble of C23 missing symbols on old systems. In > > my case it is a custom build (with tailored source) of libfreeimage which > > has some calls to `sscanf` pulling the unwanted symbol references (to > > `__isoc23_sscanf@GLIBC_2.38`) into the library > > That is not a glibc issue but rather you are thinking glibc will be forwards > compatible; glibc is not and never can be; this is true for almost all OS > out there (Mac OS has a similar issue though they provide sysroots with all > needed headers/libraries so it is slightly easier to handle rather than you > need to go out and find one). It is definitely backwards compatiable. If you > want to build a program that runs on older systems you 100% need to use the > earliest version of glibc to link (and use headers from) against rather than > the newest version. This is completely BS. Old libc cannot build with the latest gcc since the script messed up. People end up stuck with old versions of C++ standards, which is unacceptable. If GNU folks continue f things up, I can guarantee you everyone will move to LLVM
(In reply to Andrew Pinski from comment #42) > (In reply to frankhb1989 from comment #41) > > I ran into exact the same trouble of C23 missing symbols on old systems. In > > my case it is a custom build (with tailored source) of libfreeimage which > > has some calls to `sscanf` pulling the unwanted symbol references (to > > `__isoc23_sscanf@GLIBC_2.38`) into the library > > That is not a glibc issue but rather you are thinking glibc will be forwards > compatible; glibc is not and never can be; this is true for almost all OS > out there (Mac OS has a similar issue though they provide sysroots with all > needed headers/libraries so it is slightly easier to handle rather than you > need to go out and find one). It is definitely backwards compatiable. If you > want to build a program that runs on older systems you 100% need to use the > earliest version of glibc to link (and use headers from) against rather than > the newest version. https://github.com/trcrsired/glibc/commit/4a724a45761fe27000247267d6ea02cb64b17b3c#diff-e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 My patch just works perfectly. Don't know what's your opposition. I am not even suggest an ABI lock down or something
(In reply to Andrew Pinski from comment #45) > . Even Microsoft does this right with _WIN32_WINNT and _WIN32_WINDOWS macros etc, I don't know what's wrong with adding the similar mechanism for glibc.
Apple provides different sysroots for each (major) version of their OS to solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can buld gcc against majority of old sysroot just fine. I have built against the trunk of gcc against a centos 6 sysroot before (actually I have built on the trunk after it started to require C++11 on a centos 6 machine too).
Please stop resetting the bug status. You create unneeded churn. This bug is invalid. (In reply to cqwrteur from comment #43) > This is completely BS. Old libc cannot build with the latest gcc since the > script messed up. People end up stuck with old versions of C++ standards, > which is unacceptable. If GNU folks continue f things up, I can guarantee > you everyone will move to LLVM Fix the build script then, rather than breaking the compiler. (In reply to cqwrteur from comment #44) > https://github.com/trcrsired/glibc/commit/ > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > My patch just works perfectly. Don't know what's your opposition. I am not > even suggest an ABI lock down or something "WFM" is a dangerous and broken mindset that cannot be applied here. The patch above is a nonsense hack in the libc.
(In reply to Andrew Pinski from comment #47) > Apple provides different sysroots for each (major) version of their OS to > solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can > buld gcc against majority of old sysroot just fine. I have built against the > trunk of gcc against a centos 6 sysroot before (actually I have built on the > trunk after it started to require C++11 on a centos 6 machine too). I need to do Canadian compilation. I cannot install centos and I don't want eithert
(In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. How is that a nonsense hack? It just works by forcing the version to be stabilized as 2.34.
(In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. Again I do not do native compilation for linux. Do you understand? I do not native compile linux binaries. I always build linux binaries on windows
(In reply to Andrew Pinski from comment #47) > Apple provides different sysroots for each (major) version of their OS to > solve this issue. This is NOT a GCC issue nor this is a glibc issue. You can > buld gcc against majority of old sysroot just fine. I have built against the > trunk of gcc against a centos 6 sysroot before (actually I have built on the > trunk after it started to require C++11 on a centos 6 machine too). Apple? No wonder why apple bs cannot take over windows because only Microsoft does this right
(In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. https://news.ycombinator.com/item?id=32471624 Everyone disagrees with gnu's policy here. Even linus torvalds disagrees
(In reply to Arsen Arsenović from comment #48) > Please stop resetting the bug status. You create unneeded churn. This bug > is invalid. > > (In reply to cqwrteur from comment #43) > > This is completely BS. Old libc cannot build with the latest gcc since the > > script messed up. People end up stuck with old versions of C++ standards, > > which is unacceptable. If GNU folks continue f things up, I can guarantee > > you everyone will move to LLVM > Fix the build script then, rather than breaking the compiler. > > (In reply to cqwrteur from comment #44) > > https://github.com/trcrsired/glibc/commit/ > > 4a724a45761fe27000247267d6ea02cb64b17b3c#diff- > > e1c081599cb4df1d7224ee161959d04457b256c4b269e428baec5a6d34e630d1 > > > > My patch just works perfectly. Don't know what's your opposition. I am not > > even suggest an ABI lock down or something > "WFM" is a dangerous and broken mindset that cannot be applied here. The > patch above is a nonsense hack in the libc. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s
https://en.wikipedia.org/wiki/Forward_compatibility
(In reply to Andrew Pinski from comment #55) > https://en.wikipedia.org/wiki/Forward_compatibility This has nothing to do with forward compatibility. This is about satisfying C++ standard.
(In reply to cqwrteur from comment #51) > Again I do not do native compilation for linux. Do you understand? I do not > native compile linux binaries. I always build linux binaries on windows I do not see the relevance of this. You need to link and compile against some libraries and headers whereever you compile. Just use older libraries and headers. (In reply to cqwrteur from comment #49) > I need to do Canadian compilation. I cannot install centos and I don't want > eithert Nor do you need to. This was said to point out that you can use quite old systems to build GCC. Nothing about CentOS in particular is relevant. (In reply to cqwrteur from comment #50) > How is that a nonsense hack? It just works by forcing the version to be > stabilized as 2.34. No, it doesn't. It happens to coincidentally work by removing a feature test macro. The fact the result is non-obvious from the patch body corroborates what I said. (In reply to cqwrteur from comment #53) > This has nothing to do with forward compatibility. This is about satisfying > C++ standard. It has only to do with forwards compatibility. You're downgrading a library and expecting it to work. It will not without forwards compatibility. Nobody provides forwards compatibility for libraries for obvious reasons. Please stop spamming the bug tracker now.
(In reply to cqwrteur from comment #43) > If GNU folks continue f things up, I can guarantee > you everyone will move to LLVM You keep saying this, but you're still here. Feel free to leave any time.
you think it is not a reality? android freebsd wasm and even windows had already moved to llvm. GCC does not even support android any more. glibc on linux is the only reason people still stay with gcc. But now llvm is making libc. We will finally see everyone moves to llvm. Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> Sent: Monday, July 22, 2024 5:41:29 AM To: unlvsur@live.com <unlvsur@live.com> Subject: [Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #58 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to cqwrteur from comment #43) > If GNU folks continue f things up, I can guarantee > you everyone will move to LLVM You keep saying this, but you're still here. Feel free to leave any time. -- You are receiving this mail because: You reported the bug. You are on the CC list for the bug.
i am here? Have you even checked my repository? i have been working on llvm backend for my projects for nearly a year. At this point i won't even be shocked even microsoft giving up msvc and moving to llvm. Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: redi at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> Sent: Monday, July 22, 2024 5:41:29 AM To: unlvsur@live.com <unlvsur@live.com> Subject: [Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #58 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to cqwrteur from comment #43) > If GNU folks continue f things up, I can guarantee > you everyone will move to LLVM You keep saying this, but you're still here. Feel free to leave any time. -- You are receiving this mail because: You reported the bug. You are on the CC list for the bug.