Release v0.13.5 refers to libsignal-client version 0.52.2 which is no longer available

[pbiering]

Detected during RPM build for EL8.

From changelog: Requires libsignal-client version 0.52.2

But it's not available (anymore): https://github.com/exquo/signal-libs-build/releases

Can 0.52.3 also be bundled?

[m-ueberall]

@pbiering : If you don't need to pull the client from GitHub and (temporarily) trust other sources, https://github.com/AsamK/signal-cli/wiki/Provide-native-lib-for-libsignal#user-content-pre-built also lists https://gitlab.com/packaging/libsignal-client/-/artifacts and https://media.projektzentrisch.de/temp/signal-cli/ (EDIT1: non-applicable for EL8 which has glibc 2.28) https://media.projektzentrisch.de/temp/signal-cli/tests/ as possible sources for the necessary dynamic .so library.

EDIT2: Please also note that the exquo/signal-libs-build repository recently switched to a build environment based on Debian Bullseye, so newer builds require glibc 2.29.

[exquo]

Available now:

https://github.com/exquo/signal-libs-build/releases/tag/libsignal_v0.52.2

I had to run it manually, as by default my build Action runs only once a day, picking up the latest version of libsignal at that time. v0.52.3 was released just two hours after v0.52.2, so the latter build never got to run.

Don't know how such a short-lived release made it into signal-cli :) But for its purposes the two versions are essentially the same.

[pbiering]

@exquo : thank you very much! EL8 RPM build was successful now.

[exquo]

👍 Does it work on RHEL 8 though? As @m-ueberall said, these builds now require glibc version 2.29, and it looks like RHEL 8 has glibc 2.28.

[pbiering]

@exquo : hmm, good catch, did not test but trusted the selfcheck in spec, which did not cover this (so far) :-(

Build removed covering EL8 and rebuild started for EL9+Fedora only.

WARN  Manager - Failed to call libsignal-client: /tmp/libsignal13484344924690565152/libsignal_jni.so: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/libsignal13484344924690565152/libsignal_jni.so)

@m-ueberall : this updated requirement kills support for EL8 which itself has EOSL 2029-05 somehow silently already 2024-07 - was this intended?

[pbiering]

did not test but trusted the selfcheck in spec, which did not cover this (so far) :-(

ldd return code is still 0 even if it reports a problem (check now enhanced in spec file):

ldd libsignal_jni.so; echo $?
./libsignal_jni.so: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by ./libsignal_jni.so)
	linux-vdso.so.1 (0x00007ffff3990000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ffac97e6000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ffac95c6000)
	libm.so.6 => /lib64/libm.so.6 (0x00007ffac9244000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007ffac9040000)
	libc.so.6 => /lib64/libc.so.6 (0x00007ffac8c6a000)
	/lib64/ld-linux-x86-64.so.2 (0x00007ffaca3ec000)
0

[m-ueberall]

@m-ueberall : this updated requirement kills support for EL8 which itself has EOSL 2029-05 somehow silently already 2024-07 - was this intended?

@pbiering : Well, I guess @exquo made the switch to the newer Debian release so that it's guaranteed that the build container in use will continue to receive security updates/bug fixes like those for macOS, Windows.

@morph027 stuck to the older Debian release for the time being (which should still be fine for the short/medium term but at one point might be at risk with respect to detected problems which aren't fixed upstream anymore).

We recently started cross-compiling against libraries/header files from older Ubuntu LTS releases which, contrary to older Debian releases, are still supported/maintained (and should – thanks to Canonical's Expanded Security Maintenance (ESM) – have no problems matching the EL8 EOSL), see https://github.com/AsamK/signal-cli/wiki/Provide-native-lib-for-libsignal#pre-built
(Note that these builds only reside in .../tests/ right now because they're rather new and we haven't been able to conduct longer tests or received feedback – they're here to stay.)
(By the way, it's not that we didn't try, but for now, it does not seem "easy" to use a modern toolchain to produce binaries that would still work on EL7 which would require glibc v2.17 compatibility.)

[pbiering]

@m-ueberall : fetching native library from "test" worked well, EL8 build is now running - thank you!

[exquo]

@m-ueberall
Another way of building for older glibc versions is to use zig cc drop-in replacement for gcc. Its -target argument allows to specify the glibc version explicitly:

zig cc -target x86_64-linux-gnu.2.17 …

Here is the .so binary from a build targeting glibc v2.17.
I don't know whether it can actually run on a system with glibc <2.28 though, as the resulting shared library still references functions that were introduced in later version of glibc (I have added more details in a comment)

[m-ueberall]

@m-ueberall Another way of building for older glibc versions is to use zig cc drop-in replacement for gcc. Its -target argument allows to specify the glibc version explicitly:

zig cc -target x86_64-linux-gnu.2.17 …

Thanks for the above pointer (and especially for the observation regarding unsatisfiable weak symbols on systems with glibc < v2.28, for which I added my preliminary notes below your comment and which might also be of interest to @morph027).

I might try zig cc at one point, especially with respect to FreeBSD support if available (for which cross-building on Linux is nothing but a pain when using GCC/Clang) – on the other hand, zig is distributed as a Snap for Debian/Ubuntu, which … is also a pain in itself and might not work as expected in "simple schroot containers"; replacing those with LXD containers would require a bit of effort (unless schroot gains/gained support for LXD in the meantime).

But then, I first need to wrap my head around those unsatisfied weak symbols (unless @morph027 beats me to it) … 😛

EDIT: My bad, @morph027's current build environment uses/targets glibc v2.28 as well, so he's in the clear.

[exquo]

@m-ueberall
Re zig installation: the releases can be downloaded directly from https://ziglang.org/download - no need to use package managers. The binaries for Linux are fully statically linked, not requiring any external dependencies.

[m-ueberall]

@m-ueberall Re zig installation: the releases can be downloaded directly from ziglang.org/download

@exquo: Thanks again, I totally missed that before properly reading the Zig repository's README (although Andrew Kelley's article also contained a link to the downloads).

[morph027]

Just tried a quick test build w/ zig but it looks like i'm missing something in the chain. Also stumbled upon ziglang/zig#16630

ln -s /usr/local/rustup/toolchains/nightly-2024-06-21-x86_64-unknown-linux-gnu/ /usr/local/rustup/toolchains/nightly-2024-06-21-x86_64-linux-gnu.2.17
ln -s /usr/local/rustup/toolchains/nightly-2024-06-21-x86_64-linux-gnu.2.17/lib/rustlib/x86_64-unknown-linux-gnu/ /usr/local/rustup/toolchains/nightly-2024-06-21-x86_64-linux-gnu.2.17/lib/rustlib/x86_64-linux-gnu.2.17
echo -e '#!/bin/bash\nparams="$*"\nparams="${params//x86_64-unknown-linux-gnu/x86_64-linux-gnu.2.17}"\nexec /tmp/zig-linux-x86_64-0.14.0-dev.1166+bb7050106/zig cc ${params}' >/usr/bin/cc
echo -e '#!/bin/bash\nparams="$*"\nparams="${params//x86_64-unknown-linux-gnu/x86_64-linux-gnu.2.17}"\nexec /tmp/zig-linux-x86_64-0.14.0-dev.1166+bb7050106/zig c++ ${params}' >/usr/bin/c++

results in successful build, but

# objdump -T /source/libsignal-client/amd64/libsignal_jni.so | grep GLIBC | sed -e 's|.*GLIBC_||g' -e 's| .*||g' | sort -uV
2.2.5
2.3
2.3.2
2.3.4
2.7
2.9
2.12
2.14
2.16
2.17
2.18
2.25
2.28
2.29

[m-ueberall]

@morph027 : I'm guessing you're wondering about the last four symbols? These should be

2.18 __cxa_thread_atexit_impl
2.25 getrandom
2.28 statx
2.29 pow

The first three can be safely ignored (see my comment here). I'd think that this also holds true for pow, but I need to re-check.
The fact that the above symbols can be found when searching for GLIBC should mean that you built this on a system/in a configuration where the compiler, linker have access to newer glibc sources/header files. Explicitly setting CPATH and ensuring that old versions of the packages/their contents mentioned below have been installed should get rid of all GLIBC symbols above v2.17 (you don't need to explicitly provide all settings shown below which have been generated using a template):

CARGO_BUILD_TARGET="x86_64-unknown-linux-gnu"
CC="x86_64-linux-gnu-gcc"; CXX="${CC/gcc/g++}"; CPATH="/usr/x86_64-linux-gnu/include"
CARGO_LINKER="${CC}"; CARGO_AR="${CC/gcc/ar}"; CARGO_RANLIB="${CC/gcc/ranlib}"
LD="${CC/gcc/ld}"
[…]
force_install_packages "Ubuntu Raring/13.04" "libc6-dev-amd64-cross_2.17-0ubuntu5.1_all.deb,libc6-amd64-cross_2.17-0ubuntu5.1_all.deb,linux-libc-dev-amd64-cross_3.8.0-35.50_all.deb" "/repository/raring/all"

With the above settings, you should see that an older version for pow is referenced (b/c the newer one listed above is unknown as of glibc 2.17):

# grep pow .../libsignal_jni_so0522_ubuntu1304_amd64.objdump
0000000000000000      DF *UND*  0000000000000000 (GLIBC_2.2.5) pow

EDIT: You might not necessarily find the above versions of the packages when searching online for older versions of Ubuntu/Debian. However, they can always be regenerated using dpkg-cross from a subset of the below list of packages:

# ls -l /repository/raring/amd64/
total 11897
-rwxr-xr-x 1 sys-maint adm   15320 Apr 15  2013 gcc-4.7-base_4.7.3-1ubuntu1_amd64.deb
-rwxr-xr-x 1 sys-maint adm 1190492 Oct 21  2013 libc-bin_2.17-0ubuntu5.1_amd64.deb
-rwxr-xr-x 1 sys-maint adm   80188 Oct 21  2013 libc-dev-bin_2.17-0ubuntu5.1_amd64.deb
-rwxr-xr-x 1 sys-maint adm 3086172 Oct 21  2013 libc6-dev_2.17-0ubuntu5.1_amd64.deb
-rwxr-xr-x 1 sys-maint adm 4733720 Oct 21  2013 libc6_2.17-0ubuntu5.1_amd64.deb
-rwxr-xr-x 1 sys-maint adm 2463686 Apr 15  2013 libgcc-4.7-dev_4.7.3-1ubuntu1_amd64.deb
-rwxr-xr-x 1 sys-maint adm  931260 Dec  3  2013 linux-libc-dev_3.8.0-35.50_amd64.deb
# for DEB in /repository/raring/amd64/*.deb; do dpkg-cross -a amd64 -M -A --build ${DEB}; done

[exquo]

@morph027
Yes, there shouldn't be any references to glibc versions >2.17 in a .so compiled with zig cc … -target ….2.17 (see the output in https://github.com/exquo/signal-libs-build/actions/runs/10300142631/job/28508948237#step:13:24)

Re ziglang/zig#16630: the target "triplets" are indeed different for zig from the gcc / llvm style (x86_64-linux-gnu vs x86_64-unknown-linux-gnu).
(However that issue #16630 is about reading from stdin, which shouldn't be applicable here).

Here are the zig cc wrapper scripts I have used: exquo/signal-libs-build@4597143#diff-5ebe12a1851cda0190cf2ed6fcf42049b071c8eeaa9c495dc20b0adab7b1f773R203-R209

Also, need to make sure the zig cc … script is used as a linker by the rust toolchain.

[morph027]

Ah, great. By looking at your build scripts i think i've just hit the deck with target parameter needs to be the last one. Will try again later. Anyhow, thank you all for the input, haven't heard about zig before and i'm very impressed.

[morph027]

Feedback: Got it working for native compilation. Cross compilation would be nice to have too, but fails atm.

  clang -cc1 version 18.1.6 based upon LLVM 18.1.6 default target x86_64-linux-musl
  #include "..." search starts here:
  #include <...> search starts here:
   /tmp/libsignal-client/target/aarch64-unknown-linux-gnu/release/build/boring-sys-27e03c6f3e391e15/out/boringssl/src/include
   /tmp/zig/lib/libcxx/include
   /tmp/zig/lib/libcxxabi/include
   /tmp/zig/lib/libunwind/include
   /tmp/zig/lib/include
   /tmp/zig/lib/libc/include/aarch64-linux-gnu
   /tmp/zig/lib/libc/include/generic-glibc
   /tmp/zig/lib/libc/include/aarch64-linux-any
   /tmp/zig/lib/libc/include/any-linux-any
  End of search list.
  gmake: warning: -j12 forced in submake: resetting jobserver mode.
  /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
  thread 'main' panicked at /usr/local/cargo/git/checkouts/boring-b37daebd62069023/59883d7/boring-sys/build/main.rs:752:39:
  Unable to generate bindings: ClangDiagnostic("/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found\n")
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[exquo]

@morph027 👍

The cross-compilation error is caused by the build system not finding the 32-bit version of glibc files. It happens even when the target is aarch64 (logs for analogous build on RHEL).

When building for 32-bit ARM v7, this error can be sidestepped by installing libc6-dev-i386 on Debian. Here is a similar build on RHEL that installs the glibc-devel.i686 package. But doing this seems to defeat the purpose of using zig here, as now the system's versions of glibc files will be used instead of the ones for zig -target ….

I suspect this is caused by CMake trying to use the system files instead of zig..

[morph027]

arm64 cross works w/ https://github.com/rust-cross/cargo-zigbuild, but armv7 still has something against me ;)

[exquo]

Interesting.. I've tried cargo-zigbuild briefly; it failed to build for aarch64, and I have not investigated it further.