From 36d726f0a1e8207408f69cd4b5d0cde17fa554b7 Mon Sep 17 00:00:00 2001
From: Mathieu Benoit <mathben@technolibre.ca>
Date: Sun, 16 Aug 2026 22:53:33 -0400
Subject: [PATCH] [FIX] openssl: s390x is big-endian, drop the little-endian EC
 path

  crypto/ec/ec_local.h:520:2: error:
    "Can not enable ec_nistp_64_gcc_128 on big-endian systems"

Arch enables this elliptic-curve optimisation, which uses a 128-bit
integer representation that assumes little-endian byte order. s390x is
BIG-endian.

This is the first time in the whole port that endianness -- rather than
word size, instruction set or packaging layout -- decides anything. Ten
packages so far diverged on 32-bit multilib, missing front ends or path
conventions; this one diverges on how bytes are ordered in a word.

OpenSSL refuses at compile time rather than producing wrong results,
which is the right call and makes this one honest to diagnose. Dropping
the flag costs some NIST curve performance and nothing else: the curves
still work through the portable implementation.

--- FR ---

  crypto/ec/ec_local.h:520:2: error:
    "Can not enable ec_nistp_64_gcc_128 on big-endian systems"

Arch active cette optimisation de courbes elliptiques, qui repose sur
une representation entiere 128 bits supposant l ordre petit-boutiste.
s390x est GROS-boutiste.

C est la premiere fois dans tout le portage que l endianness -- et non
la taille de mot, le jeu d instructions ou la convention de chemins --
tranche quoi que ce soit. Dix paquets ont diverge jusqu ici sur le
multilib 32 bits, des frontaux absents ou des dispositions de
repertoires ; celui-ci diverge sur l ordre des octets dans un mot.

OpenSSL refuse a la compilation plutot que de produire des resultats
faux, ce qui est le bon choix et rend ce cas honnete a diagnostiquer.
Retirer l option coute un peu de performance sur les courbes NIST, et
rien d autre : elles fonctionnent par l implementation portable.

Assisted-by: Claude Opus 5
---
 patches/pkgbuild/openssl.sh | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/patches/pkgbuild/openssl.sh b/patches/pkgbuild/openssl.sh
index 21e9291..8b3311a 100755
--- a/patches/pkgbuild/openssl.sh
+++ b/patches/pkgbuild/openssl.sh
@@ -23,3 +23,22 @@ io.open("PKGBUILD", "w", encoding="utf-8").write(s)
 PY
 grep -q '"s390x" | "riscv64")' PKGBUILD || { echo "openssl: case not extended" >&2; exit 1; }
 echo "openssl: Configure target set to linux64-s390x (linux-s390x is 31-bit)"
+
+# enable-ec_nistp_64_gcc_128: little-endian only.
+#
+#   crypto/ec/ec_local.h:520:2: error:
+#     "Can not enable ec_nistp_64_gcc_128 on big-endian systems"
+#
+# Arch turns on this elliptic-curve optimisation, which uses a 128-bit
+# integer representation that assumes little-endian byte order. s390x is
+# BIG-endian -- the first time endianness, rather than word size or
+# instruction set, decides anything in this port.
+#
+# OpenSSL refuses at compile time rather than producing wrong results, which
+# is the right behaviour and makes this one honest to diagnose. Dropping the
+# flag costs some NIST curve performance and nothing else: the curves still
+# work through the portable implementation.
+sed -i '/enable-ec_nistp_64_gcc_128/d' PKGBUILD
+grep -q 'enable-ec_nistp_64_gcc_128' PKGBUILD && {
+    echo "openssl: little-endian EC optimisation still enabled" >&2; exit 1; }
+echo "openssl: ec_nistp_64_gcc_128 disabled (s390x is big-endian)"