Closed glaubitz closed 1 month ago
I had to apply the below patch using cargo patch
when building the current libsignal_jni.so
(see https://github.com/signalapp/libsignal) – which pulls in ring
v0.17.8 – for the sparc64
architecture; all other architectures (amd64
, arm64
, mips64el
, armv7
, ppc64
, ppc64el
, s390x
, i686
, riscv64
) worked out of the box:
diff -U2 -r ring.upstream/include/ring-core/target.h ring/include/ring-core/target.h
--- ring.upstream/include/ring-core/target.h 1973-11-29 22:33:09.000000000 +0100
+++ ring/include/ring-core/target.h 2024-04-28 17:27:31.805358732 +0200
@@ -61,4 +61,10 @@
#elif defined(__s390x__)
#define OPENSSL_64_BIT
+#elif defined(__sparc__)
+#if defined(__LP64__)
+#define OPENSSL_64_BIT
+#else
+#define OPENSSL_32_BIT
+#endif
#else
#error "Unknown target CPU"
It would be great if one of you could submit that patch as a PR, and it would be great if you could append mk/install-build-tools.sh and mk/cargo.sh and .github/actions/ci.yml to add this target to the test suite so we ensure it keeps working. I believe we need to also upgrade our dependency of getrandom
and probably libc
to newer versions.
It would be great if one of you could submit that patch as a PR, and it would be great if you could append mk/install-build-tools.sh and mk/cargo.sh and .github/actions/ci.yml to add this target to the test suite so we ensure it keeps working. I believe we need to also upgrade our dependency of
getrandom
and probablylibc
to newer versions.
Just opened #2066 which I verified to work on 64-bit SPARC on Debian Linux.
[…] and it would be great if you could append mk/install-build-tools.sh and mk/cargo.sh and .github/actions/ci.yml to add this target to the test suite so we ensure it keeps working. I believe we need to also upgrade our dependency of
getrandom
and probablylibc
to newer versions.
Sorry, but we're exclusively using our own internal build environments (with a heavily modified/modernised tool-chain based on Ubuntu 20.04/Focal for the arm64/aarch64
, amd64/x86_64
, riscv64
architectures; artefacts for other architectures are currently built using cross-compilation); therefore, modifying the above definitions/workflow might be easier for those users/contributors that actually use the GitHub infrastructure (and maybe also work with ring
directly instead of pulling it in as a dependency) without having to analyse the available environments first.
What I can do is drop our own patch, pull in the above PR (until it is merged), and provide you with feedback whenever future builds start to fail.
It is easy to modify mk/[install-bulid-tools.sh,cargo.sh}/ci.yml
without running them locally exactly because they are run in GitHub Actions in CI. It makes it much easier for me to review the PRs that add the ports when they are run in CI. Basically, I'm asking you to help me help you.
It is easy to modify
mk/[install-bulid-tools.sh,cargo.sh}/ci.yml
without running them locally exactly because they are run in GitHub Actions in CI. It makes it much easier for me to review the PRs that add the ports when they are run in CI. Basically, I'm asking you to help me help you.
OK, sorry, I missed that. I need to have a closer look at the necessary changes.
I suggested a more general approach to this issue in https://github.com/briansmith/ring/pull/2042#issuecomment-2120898907. I would prefer that approach to be taken because it eliminates the allowlist of target architectures.
I suggested a more general approach to this issue in #2042 (comment). I would prefer that approach to be taken because it eliminates the allowlist of target architectures.
Fine with me. Do you still want the CI-related changes?
Fine with me. Do you still want the CI-related changes?
I would recommend contributing the CI changes if people want any help in the future related to diagnosing any SPARC-related issues and to ensure that SPARC codegen in new versions of Rust doesn't break something here. This will become increasingly important as we add additional QA (tests) for things like side channels.
Closing as a duplicate of the just-reopened #1512, since there's more recent discussion in that issue.
Despite the changes in #1555, ring still fails to build on Linux SPARC:
Access to SPARC machines can be obtained through the GCC Compile Farm: https://gcc.gnu.org/wiki/CompileFarm