[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 64-bit time_t on glibc 2.34 and up
From: |
Hal Murray |
Subject: |
Re: 64-bit time_t on glibc 2.34 and up |
Date: |
Sat, 14 Jan 2023 07:51:13 -0800 |
Greg via Gary said:
> Does Linux version syscalls? In NetBSD, we change the codepoints when the
> ABI changes, and there is kernel code to implement the old codepoint (but no
> header support) so old binaries still work. I think Solaris does this too.
They do something like that. I'm not familiar with the details but there are
lots of syscalls with names like foo64 to go with foo.
There are differences between architectures.
This all gets tangled up with the libraries too. You either have to link
against old/new libraries or you have to change the name that "time", for
example, links to. I think the _TIME_BITS stuff changes the definition of time
so it links to another name. (That's from a quick scan of the header files.
I'd have to look much harder if you want any details.)
> shmTime is simply using time_t, so it inherits the definition of time_t from
> the compilation environment. POSIX says that <sys/time.h> is required to
> define time_t:
If you #define _TIME_BITS 64 you get a different time_t.
--
These are my opinions. I hate spam.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: 64-bit time_t on glibc 2.34 and up,
Hal Murray <=