exquo / signal-libs-build Goto Github PK

I would like to use a plugin which pulls in libsignal_jni.so distributed here.
Unfortunately the dynamic linking fails as your build is for AMD64/glibc (the most common variant), whereas my platform OpenWRT uses AMD64/musl. A more prominent example would be Alpine Linux.

Would it be possible to add AMD64/musl to the list of targets you provide builds for?
The rust target triple is: x86_64-unknown-linux-musl

signal-cli is currently signed, which is useful to avoid trusting HTTPS on every download, however libsignal releases are not. Since using a release means replacing a shared library, the security is reduced to that of libsignal. So I’m asking whether you could also sign libsignal release, automatically in the workflow files. If you agree, I recommend using signify or just ssh keys. No GPG please as it requires a stateful keyring.

It would be cool to be able to link people to the latest graal builds, I don't know if that might be a good fit for this repo?

I try to run signal-cli on a RPI4 with "arm_64bit=0" set in config.txt. I have to set that because other sqlite lib problems.

If I use aarch64-linux-gnu I get wrong ELF class: ELFCLASS64 (Possible cause: can't load AARCH64 .so on a ARM platform)

If I use the arm7 lib I get org.signal.libsignal.zkgroup.InvalidInputException: Deserialization failure in zkgroup (AssertionError)

What can I do?

I used https://github.com/exquo/signal-libs-build/releases/download/v0.8.4.1/signal-cli-v0.8.4.1-x86_64-Linux.tar.gz and I got

OpenJDK Server VM warning: You have loaded library /tmp/resource17548792288693908275.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
WARN App - WARNING: Support for new group V2 is disabled, because the required native library dependency is missing: libzkgroup
Missing required native library dependency: libsignal-client

uname -m says i686

Looks like compiling 0.20.0 failed for some reason. There are no compiled files in assets.

https://github.com/exquo/signal-libs-build/releases/tag/libsignal-client_v0.19.3 Is missing it's assets as https://github.com/exquo/signal-libs-build/actions/runs/2844397155 failed.

this updated requirement kills support for EL8 which itself has EOSL 2029-05 - was this intended?

ldd libsignal_jni.so
./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)

Last "known-good": 0.52.0

Can this be circumvented and GLIBC 2.28 support can be kept over the next years?

This is related to AsamK/signal-cli#1560

I may just be over my head here but maybe others are also struggling? I did the following:

1. Downloaded signal-cli .tar.gz archive for v0.11.5.1 from AsamK/signal-cli, followed instructions on README there to extract and create link
2. Downloaded appropriate tar.gz archive for v0.21.1 from this repo and folled instructions on README here to swap out the .so file in the libsignal-client .jar archive set up in step 1

But still get "ServiceConfig - Failed to call libsignal-client: [filename].so: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by [filename].so)
Missing required native library dependency: libsignal-client"

Using Ubuntu 18.

My packaging pipeline fails due to v0.52.2 is missing for signal-cli v0.13.5

Also see AsamK/signal-cli#1560

hello there, thanks for your awesome repo.

do you think it would make sense to go the extra mile and publish full releases with such libraries included?

for example, for ARM64 one has to download your libraries, download the latest signal version, upgrade the libs in the tarfile and then install.
would it be easy for you to publish the whole updated archives?
that would speed up the process for any user to install.

I am trying to run the latest signal-cli v0.13.0 which requires libsignal-client version 0.39.2. I am running on x86_64 with Ubuntu 20.04.

So I downloaded libsignal_jni.so-v0.40.1-x86_64-unknown-linux-gnu.tar.gz and replaced:

zip -uj signal-cli-0.13.0/lib/libsignal-client-0.39.2.jar libsignal_jni.so

When I run signal-cli, I get the following error:

fatal runtime error: failed to initiate panic, error 5
Aborted (core dumped)

Would it be possible to create a binary buld for a Raspberry Pi B (armv6l)?

I'm trying to get your prepacked 'signal-cli-v0.8.5-x86_64-Linux.tar.tz' up and running in Cygwin BASH under Windows10. And I'm stuck getting the error message that libzkgroup and libsignal-client are missing. Is there something I overlooked? I assumed that the pre-compiled Linux variants would also work 'out-of-the-box' also on the cygwin.

java -version: java version "14.0.2" 2020-07-14
uname -m : x86_64

Thanks, no2spc

Moin,
getting the following error at build_jni.sh:

# ./build_jni.sh desktop'
cargo build -p libsignal-jni --release
error: failed to parse manifest at `/data-crypt/share/home/signal/libsignal-client/Cargo.toml`

Caused by:
  feature `resolver` is required

  consider adding `cargo-features = ["resolver"]` to the manifest

What can I do? Sorry, I have not much knowledge about rust and manifests.
I'm using newest Debian 11.2.

# cargo --version
cargo 1.46.0
# uname -m
armv7l

Thanks for your work!

After the BoringSSL lib has been added as a dependency of libsignal, cross-compiling the latter fails for target armv7-linux-gnueabihf:
https://github.com/exquo/signal-libs-build/actions/runs/3411284904/jobs/5675310584

However, building the boring library itself for the same target in the same environment succeeds..
https://github.com/exquo/signal-libs-build/actions/runs/3411698940/jobs/5676237923

Asked upstream: signalapp/libsignal#481 (comment)

GitHub does not currently provide publicly-available runners on MacOS 11:
https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

My attempts to cross-compile for aarch64-apple-darwin target from GitHub's macos-10.15 runner have so far failed with

error: linking with `cc` failed: exit status: 1

Ref issue on signal-cli's tracker: AsamK/signal-cli#660

duplicate of #9 sorry.