Backport Erlang time64 patch

[tianon]

This is currently causing build failures on 32bit architectures for 4.0 (where we updated to Ubuntu 24.04):

/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"

This is the same patch applied by Debian and Ubuntu to fix the same problem (and applied there in both Erlang 25 and 26, as we have here, so I've applied it across both for simplicity/consistency).

See also:

• otp: Fix build on Yocto erlang/otp#7952
• https://bugs.debian.org/1067701
• https://salsa.debian.org/erlang-team/packages/erlang/-/blob/89c4e190c6d1d7ee0133d9a8d6bf651ff1861e46/debian/patches/time64.patch

[lukebakken]

Thanks!

[michaelklishin]

That's extremely generous of the maintainers of this image to care even one bit about 32-bit environments.

[tianon]

A perfectly reasonable alternative would be to amend our generate-stackbrew-library.sh script to simply exclude all 32bit architectures, but this fix seems relatively unobtrusive, and it's not like we really prioritized even looking into it (it's been failing since we merged 4.x, but other versions will be failing once they update to Ubuntu 24.04). 😄

[michaelklishin]

It's your call but Team RabbitMQ has stopped caring about 32-bit Erlang runtime support years ago.

[tianon]

Definitely worth considering -- IMO, it'd make sense to use 4.0 as a turning point if we want to do that. 🤔

Concretely, this is i386, arm32v6, and arm32v7. Raspberry Pi users tend to be very vocal, so I have some concern about that, but if we do it only for 4.0+ I think we can communicate that effectively.

[tianon]

@yosifkit @lukebakken thoughts? If we want to update the older versions to Ubuntu 24.04 as well we'll either need this patch (if we remove 32bit arches from only 4.0+) or to go for a broader breaking change (removing 32bit arches from all versions).

I'm happy to make the changes, but I don't think I should be the sole decision maker -- I don't mind keeping them and deciding to remove them only if/when the next build issue requires more than one simple backported patch, but I also don't feel strongly about keeping them around if y'all think we should follow suit and remove them here too. 👍

[michaelklishin]

If supporting 32-bit is primarily for Raspberry Pi, I guess it'd make sense to keep it. In fact, that would explain some of the questions about 32-bit Debian packages we get from time to time, and indeed those folks are usually much more vocal than "average."