Re: Android and iOS triplets are not recognized

On Wed, 4 Mar 2020, Jeffrey Walton wrote: > Unfortunately, none of these are recognized: > > armv7a-android-linux > aarch64-android-linux > x86-android-linux > i686-android-linux > x86_64-android-linux > amd64-android-linux config.sub has canonicalized these since config.

Re: Future plans for Autotools

On Tue, 26 Jan 2021, Richard Purdie wrote: > I've also not seen mention of it but the fact that GCC and the > toolchain use an ancient version of autoconf has always been rather sad > to me. I moved GCC from 2.64 to 2.69 in 2018 (building on Simon Marchi's implementation of the same move for bin

Re: Future plans for Autotools

On Wed, 27 Jan 2021, Richard Purdie wrote: > Thanks, I hadn't realised. The only two recipes we never autoreconf are > binutils and gcc, instead we do some painful things to handle libtool > issues so we get our libtool tweaks. It sounds like we should revisit > that. I guess we were so used to no

Re: On time64 and Large File Support

On Fri, 11 Nov 2022, Paul Eggert wrote: > One possible way forward would be for glibc to change its defaults for > _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This See my notes at on what would be i

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote: > These are also a trip hazard for novices, and the only way to turn them > off is with -std=cXX, which also turns another trip hazard (trigraphs) > *on*… so yeah, anything you can do to help speed up their removal, I > think it’d be worthwhile. A

Re: configure adds -std=gnu++11 to CXX variable

On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote: > -std=gnu23 support is still incomplete even in GCC 14. It doesn't involve ABI issues, however, unlike C++, so using the option with GCC 14 is comparatively safe. (It might run into a few aliasing bugs related to tag compatibility right now, b