[Bug libstdc++/115907] New: Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[Bug libstdc++/115907] New: Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

            Bug ID: 115907
           Summary: Libstdc++ and GCC itself should avoid glibc above 2.34
                    dependency
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
Created attachment 58652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58652&action=edit
dependency

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #7 from cqwrteur <unlvsur at live dot com> ---
Created attachment 58654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58654&action=edit
patch

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #8 from cqwrteur <unlvsur at live dot com> ---
this is the patch. avoid using it thank you

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #9 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #10 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #11 from cqwrteur <unlvsur at live dot com> ---
(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?

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #12 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #13 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Arsen Arsenović <arsen at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---
                 CC|                            |arsen at gcc dot gnu.org

--- Comment #15 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #17 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #18 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #20 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #21 from cqwrteur <unlvsur at live dot com> ---
(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?

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #22 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The c++ frontend has defined _GNU_Source since at least 2001.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #24 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
_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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #26 from cqwrteur <unlvsur at live dot com> ---
> 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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #27 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #28 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #29 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #30 from cqwrteur <unlvsur at live dot com> ---
(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]$

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #31 from cqwrteur <unlvsur at live dot com> ---
> 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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #32 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #33 from cqwrteur <unlvsur at live dot com> ---
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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #36 from cqwrteur <unlvsur at live dot com> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #37 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #38 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(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).

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #39 from cqwrteur <unlvsur at live dot com> ---
> > 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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #40 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.
This discussion now belongs in gcc-help@ rather than bugzilla since there is no
GCC bug here.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[frankhb1989 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

frankhb1989 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frankhb1989 at gmail dot com

--- Comment #41 from frankhb1989 at gmail dot com ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #42 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #43 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #44 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #46 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #47 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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).

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #48 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #49 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #50 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #51 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #52 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #53 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #54 from cqwrteur <unlvsur at live dot com> ---
(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

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #55 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://en.wikipedia.org/wiki/Forward_compatibility

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #56 from cqwrteur <unlvsur at live dot com> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[arsen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

Arsen Arsenović <arsen at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #57 from Arsen Arsenović <arsen at gcc dot gnu.org> ---
(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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #59 from cqwrteur <unlvsur at live dot com> ---
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.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

[unlvsur at live dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907

--- Comment #60 from cqwrteur <unlvsur at live dot com> ---
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.