Does 2038y problem sovled on mipsel? (I told about kernel and libc in total)
Why wouldn't it? It's not hard to use 64 bits counter and calculations on a 32 bits CPU. However, while kernel and libc will support a 64 bits time_t just fine, a possible rtc in your device might not be able to keep time beyond 2038. (Of course the odds are not great that it will survive until then anyway)
I saw that debian drop support for mipsel because of y2038 problem and 2gb of userspace address space
Where did you read that? Here I read that a generic problem of Mipsel is the 2GiB user space, which causes problems on build machines, that Trixie won't support Mipsel, and that CIP United is maintaining an Y2038-fixed version of Mipsel.
But no connection between those individual facts.
So i readed all of this there
- The link you posted isn't related to OpenWrt
- What you linked references 32-bit devices
- Lastly, you missed "MIPS64EL as the 64-bit little-endian variant will continue to be maintained"
- I need to run little debian chroot enviroment
2.Because mipsel(most) is 32bit - Mt7621 this cpu is currently in my routers is 32bit
According to the mailing list, where phoronix points to, the Y2038 problem could be solved for Debian, but requires almost rebootstrap. Linux uses since 5.6 only 64 bits time inside, both for 32 and 64 bits architectures. For all ABI calls which requires time to be transferred between kernel en userspace, there are 2 versions, one for 32 bits time, and one for 64 bits time. To be able to use the 32 bits calls CONFIG_COMPAT_32BIT_TIME=y has to be set in the kernel config. Without that flag the calls will be unavailable.
I think the Debian Mipsel port still uses 32 bits calls in libc, and maintainers don't think its worth the effort to port that.
As long as the ABI used by libc of your chroot is supported by the kernel, it should work. But if OpenWrt omits the 'CONFIG_COMPAT_32BIT_TIME=y' flag, your chroot will no longer work. And I wouldn't be surprised if it would be omitted. Why keep an ABI which is not needed for OpenWrt and only costs memory and flash space?
@Catmengi - can you clarify or confirm that you're trying to implement this on OpenWrt?
The reason for this is glibc specific. OpenWrt uses musl which does not have this problem.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.