Hello Erwin.
On 5/27/24 10:32 AM, Erwin Rol wrote:
[You don't often get email from mailingli...@erwinrol.com. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification ]
On 5/24/24 12:19, Michael Olbrich wrote:
On Fri, May 24, 2024 at 11:04:24AM +0200, Erwin Rol wrote:
On 5/24/24 10:41, Ian Abbott wrote:
If I figure it out I'll let you guys know (so it can be added to the
official Toolchain)
Rememember to define _FILE_OFFSET_BITS=64 too if it is not already
defined. _TIME_BITS=64 is ineffective when _FILE_OFFSET_BITS=32 for
Glibc policy reasons.
I tried some things to convince the Toolchain project (latest gcc13 release)
to use those two defines, but without much luck. Sometimes parts complained
that there were duplicate declarations of (time) functions, with some other
tries it actually complained the the _FILE_OFFSET_BITS was missing for some
part, that I really don't understand because I added them always in pairs.
So I believe it is just a bit too early for 100% year 2038 compliance at the
moment. Especially when it comes to C++/libstd++ there is also not much info
online.
But the C part seems to work with the support ptxdist offers, and C++ has
always been some unwanted stepchild, especially now Rust is going to safe
the world :-)
So gcc-14 has a --enable-year2038 configure option, but I didn't test if it
works.
Any ETA for a gcc14 ptxdist Toolchain ?
You can always roll your own toolchain?
Esp. If you need to test things. ct-ng toolchains work pretty much as is.
Atleast that's what I always do.
But I don't know if that causes any API or ABI incompatibilities.
The changelog says "Disable year2038 by default on 32-bit hosts.". That
looks a bit suspicious to me.
Maybe make 2 specific 32bit toolchains, one with TIME_BITS=32 and one
with TIME_BITS=64? So ppl (like me) can start testing the TIME_BITS=64
version, and ppl that know for sure they do not care about y2038 can
keep using the TIME_BITS=32 version ?
- Erwin
Regards,
Christian
