support for 32-bit devices

[robertkirkman]

Describe the bug
I understand that 32-bit devices are officially not supported currently. It does not need to be supported soon and I understand this may be low-priority. This issue is just to track the status of support for 32-bit devices.

To Reproduce
Steps to reproduce the behavior:

1. Attempt to compile on a 32-bit device

Expected behavior
Hopefully one day in the future there can be 32-bit support

Screenshots and charts

error: static assertion failed due to requirement 'sizeof(HeapMeta) == 16':
sizeof(HeapMeta) must be 16 to guarantee alignment
  169 |             sizeof(HeapMeta) == 16,
      |             ^~~~~~~~~~~~~~~~~~~~~~

Desktop (please complete the following information):

• OS: GNU/Linux 32-bit x86
• Version: 0.1.0
• Compiler: gcc
• Flags: None
• Other relevant hardware specs: 32-bit x86 CPU
• Build system: CMake

Additional context

I tried to edit the code and compile it anyway by doing this,

--- a/src/openzl/common/allocation.c
+++ b/src/openzl/common/allocation.c
@@ -134,6 +134,9 @@ size_t ALLOC_Arena_memUsed(const Arena* arena)
 typedef struct {
     size_t index;
     size_t size;
+#ifndef __LP64__
+    uint64_t _pad;
+#endif
 } HeapMeta;
 
 DECLARE_VECTOR_POINTERS_TYPE(HeapMeta)

and I also tried to compile it on a 32-bit ARM device in addition to a 32-bit x86 device, while trying to compile the tests using -DOPENZL_BUILD_TESTS=ON, but unfortunately this other error also happened:

ld.lld: error: relocation R_ARM_REL32 cannot be used against symbol 'typeinfo for openzl::tools::io::InputSetStatic::IteratorStateStatic'; recompile with -fPIC

[barracuda156]

I confirm the same error on

openzl/src/openzl/common/allocation.c

Lines 168 to 170 in c9a779e

	ZL_STATIC_ASSERT(
	sizeof(HeapMeta) == 16,
	"sizeof(HeapMeta) must be 16 to guarantee alignment");

on 32-bit powerpc.

[Cyan4973]

There are a lot of little details to get right in order for 32-bit to work correctly.
Beyond the immediate compilation failures, there are other aspects that are invisible at compilation time, and need to be properly taken care of. Memory allocation limits, size_t width difference, overflows, etc.
All this is technically doable, but costs time, both to implement and then maintain.

32-bit support is within scope for openzl,
but we decided to not make it an immediate goal.
This will come later, as the major components of openzl stabilize a bit.

[barracuda156]

@Cyan4973 I think it is fine to issue a warning that at the moment 32-bit builds are untested, but it is fine and desirable to do incremental fixes, as that makes it more likely it is eventually done, and leaves progressively less to be fixed later.

[Cyan4973]

I'm fine with this progressive approach