macOS 27: bundled libchdb.so fails to dlopen (mis-aligned LINKEDIT string pool)

[jasonkuhrt]

maple start cannot open chDB on macOS 27.0 (26A428, Apple silicon). dyld rejects the bundled library:

@maple/cli/ChdbError: Failed to open library ".../libchdb.so": dlopen(.../libchdb.so, 0x0001):
  tried: '.../libchdb.so' (mis-aligned LINKEDIT string pool, fileOffset=0x13148434)

Reproduced with the aarch64-apple-darwin bundles of both v0.0.21 and v0.0.22 (the libchdb.so in the two is laid out identically). It is independent of Maple's own code: python3 -c 'import ctypes; ctypes.CDLL("libchdb.so")' fails the same way.

Cause. The Mach-O string table starts at a file offset that is 4-byte but not 8-byte aligned, and macOS 27's dyld now requires 8:

$ otool -l libchdb.so | grep -A5 LC_SYMTAB
  symoff 317875512
   nsyms 131481
  stroff 320111668      # 0x13148434, % 8 == 4
 strsize 11613232

The indirect symbol table right before it holds an odd number of 4-byte entries (nindirectsyms 33115), and the linker that produced the library did not pad after it. Libraries linked with Apple's ld have stroff % 8 == 0 (checked against Homebrew's libzstd and libssl). Apple's strip -x re-lays out LINKEDIT but does not pad either, so it is not a workaround.

Workaround that loads. Remove the ad-hoc signature (codesign --remove-signature), insert 4 zero bytes before the string pool (bump LC_SYMTAB.stroff and the __LINKEDIT segment's filesize by 4), and re-sign (codesign -f -s -). After that dlopen succeeds on macOS 27.0.

Fix. Link the macOS libchdb so the string table is 8-byte aligned (Apple's ld, or an lld new enough to pad it), or post-process the bundled library the same way before publishing. If the library comes unmodified from chdb-io/chdb, this probably belongs there too. #789 (using the chdb npm package) would also change which binary gets loaded.