docker-library / rabbitmq

Docker Official Image packaging for RabbitMQ
http://www.rabbitmq.com/
MIT License
785 stars 417 forks source link

Backport Erlang time64 patch #715

Closed tianon closed 4 months ago

tianon commented 4 months ago

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:

michaelklishin commented 4 months ago

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

tianon commented 4 months ago

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 commented 4 months ago

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

tianon commented 4 months ago

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

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 commented 4 months ago

@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. :+1:

michaelklishin commented 4 months ago

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."