Include openssl and ICU statically linked

[rahulinux]

Problem

Due to the upcoming End of Life (EOL) for Debian 11, we need to upgrade
the base OS for Pageservers from Debian 11 to Debian 12 for security reasons.

When deploying a new Pageserver on Debian 12 with the same binary built on
Debian 11, we encountered the following errors:

could not execute operation: pageserver error, status: 500, 
msg: Command failed with status ExitStatus(unix_wait_status(32512)): 
/usr/local/neon/v16/bin/initdb: error while loading shared libraries: 
libicuuc.so.67: cannot open shared object file: No such file or directory

and

could not execute operation: pageserver error, status: 500, 
msg: Command failed with status ExitStatus(unix_wait_status(32512)):
 /usr/local/neon/v14/bin/initdb: error while loading shared libraries: 
 libssl.so.1.1: cannot open shared object file: No such file or directory

These issues occur when creating new projects.

Summary of changes

• To address these issues, we configured PostgreSQL build to use
  statically linked OpenSSL and ICU libraries.

• This resolves the missing shared library errors when running the
  binaries on Debian 12.

Closes: https://github.com/neondatabase/cloud/issues/12648

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[rahulinux]

@tristan957 I'm trying to build static binary and would like to know if this option is enough to have libssl?

[github-actions]

3192 tests run: 3053 passed, 0 failed, 139 skipped (full report)

---

Flaky tests (2)

Postgres 16

• test_download_remote_layers_api: debug

Postgres 14

• test_download_remote_layers_api: release

Code coverage* (full report)

• functions: 31.5% (6598 of 20937 functions)
• lines: 48.5% (51057 of 105314 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
3f62675 at 2024-06-07T17:39:05.665Z :recycle:}

[tristan957]

I wouldn't think so. Wouldn't you need something as discussed in https://stackoverflow.com/questions/6578484/telling-gcc-directly-to-link-a-library-statically?

[tristan957]

What is the output of ldd after the latest push?

[tristan957]

Why can we just not recompile the pageservers postgres binaries?

[rahulinux]

Why can we just not recompile the pageservers?

Thtat's good point and we have encountered this libs missing issue when creating new project. its uses /usr/local/neon/v16/bin/initdb

Maybe someone from Storage team can explain this better on why its uses initdb @jcsp

[rahulinux]

What is the output of ldd after the latest push?

Result from my local build:

ldd /usr/local/pgsql/bin/initdb
	linux-vdso.so.1 (0x0000ffffba1f6000)
	libpq.so.5 => /usr/local/pgsql/lib/libpq.so.5 (0x0000ffffb7d89000)
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000ffffb7bb1000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000ffffb7b06000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffffb7ad5000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffffb7ac1000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000ffffb7a9d000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffffb7929000)
	/lib/ld-linux-aarch64.so.1 (0x0000ffffba1c6000)

old build:

ldd /usr/local/neon/v16/bin/initdb
	linux-vdso.so.1 (0x00007ffc4db3b000)
	libpq.so.5 => not found
	libicuuc.so.67 => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faeca0b8000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007faeca0b3000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faec9fd4000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faec9df1000)
	/lib64/ld-linux-x86-64.so.2 (0x00007faeca0f6000)

[kelvich]

So we are bringing newer openssl and icu to match versions on the destination Linux. IMO it should work with both static and dynamic linking. Static is more reliable, but if it causes troubles we can roll that back to dynamic.

[hlinnaka]

So we are bringing newer openssl and icu to match versions on the destination Linux.

OpenSSL seems fine.

ICU might be problematic. When the ICU version number changes, you will start to get a notice like this when you connect to a database that was created with the older version:

WARNING:  database "postgres" has a collation version mismatch
DETAIL:  The database was created using collation version 153.14.37, but the operating system provides version 153.120.42.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

That's probably OK, I'm not aware of any ICU collation changes that would be likely to hit (glibc updates have been more problematic in the past). But an entry in the public-facing changelog and a heads up to the support team would be in order.