Your message dated Wed, 2 Sep 2026 09:27:50 +0200
with message-id <[email protected]>
and subject line Re: Bug#1107859: libffi-dev: Can't link libffi_pic.a to large
binaries like chromium on loong64
has caused the Debian Bug report #1107859,
regarding libffi-dev: Can't link libffi_pic.a to large binaries like chromium
on loong64
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1107859: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1107859
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libffi-dev
Version: 3.4.8-2
Severity: normal
Tags: patch
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: loong64
Chromium is linking libffi staticly. While on LoongArch64 platform the
default code model
provides 256MiB PC-relative addressing space[1], which is not enough for
chromium.
I will get following errors like:
ld.lld-19: error:
/lib/loongarch64-linux-gnu/libffi_pic.a(prep_cif.o):(function
ffi_prep_cif_core: .text+0x2b8): relocation R_LARCH_B26 out of range:
157436696 is not in [-134217728, 134217727]; references 'abort'
After recompiling libffi with code model medium, chromium can get linked
fine.
Here is my patch setting medium code model:
diff --git a/debian/rules b/debian/rules
index 87e4467..7ad92a9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,13 @@ CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
+# This will enable linking libffi staticly with large binaries like
chromium.
+# For more details, see:
+#
https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc#code_models
+ifeq (loong64,$(DEB_HOST_ARCH))
+CFLAGS += -mcmodel=medium
+endif
+
ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
with_check = yes
else
-- System Information:
Debian Release: 13.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: loong64 (loongarch64)
Foreign Architectures: amd64
Kernel: Linux 6.15-loong64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8),
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libffi-dev depends on:
ii libffi8 3.4.8-2
libffi-dev recommends no packages.
libffi-dev suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On 9/2/26 05:10, Jianfeng Liu wrote:
Hi,
Now gcc 16 has made medium as their default mcmodel since v16.2.0:
https://github.com/gcc-mirror/gcc/commit/cc3ade6da5c4b7d55425a15f25325ae84ef945a2
The commiter Xi Ruoyao said in the commit msg:
I also had some concern about a potential performance regression
caused by the conservative nature of the relaxation process, but
when I tested this patch it turned out the relaxation is powerful
enough to eliminate all the pcaddu18i instructions in
cc1plus and libstdc++.so.
So I think building dynamic libraries with medium mcmodel should be
fine now.
ok, then just closing the issue.
once gcc-defaults migrates to testing, please schedule binNMUs for all
relevant packages, that need a no-change rebuild.
--- End Message ---
