On 08/11/2022 19:38:06+0100, Alexander Kanavin wrote: > Thanks. But: face, meet palm. > > "If _TIME_BITS is undefined, the bit size of time_t is architecture > dependent. Currently it defaults to 64 bits on most architectures. > Although it defaults to 32 bits on some traditional architectures > (i686, ARM), this is planned to change and applications should not > rely on this. " > > No one needs to know or care about this, they should just set it to 64 > for all targets, break all the badly written userspace and move on. >
Note that this may build but not run properly as there is no way to know whether userspace stores a time_t in an int at some point. > Anyway, rather than add exceptions all over the core layers, I'd > suggest that you set it to 64, 'bitbake world' with all of meta-oe, > then send fixes upstream for everything that breaks. Rinse, repeat. > Then when the 'planned to change' actually happens we should be ready > for it. > So we may not be ready unless the rinse/repeat also includes runtime testing. On Monday, I was suggesting to RP that we should probably have a poky distro with _TIME_BITS set to 64 and run that on the autobuilders. I don't think we can just add the flag and be done and this is a flag day and may break existing users. I'm usually getting customers to define their own distro and stop depending on poky but it is not the case of everyone. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#173031): https://lists.openembedded.org/g/openembedded-core/message/173031 Mute This Topic: https://lists.openembedded.org/mt/94880633/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
