Package: libstdc++-arm-none-eabi
Version: 20
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Hi Keith,
libstdc++-arm-none-eabi has been stuck in Ubuntu since version 18, with all
related autopkgtests failing. Tracking this down, I find that the problem
is g++ is trying to call lto1:
[...]
arm-none-eabi-g++ multiram.cc ../../startup/startup_ARMCM0.S -mthumb
-mcpu=cortex-m0 -D__NO_SYSTEM_INIT -Os -flto -ffunction-sections
-fdata-sections -D__STARTUP_COPY_MULTIPLE -D__STARTUP_CLEAR_BSS_MULTIPLE
-fno-exceptions --specs=nano.specs --specs=rdimon.specs -L. -L../../ldscripts
-T multi-ram.ld -Wl,--gc-sections -Wl,-Map=multiram.map -o multiram-CM0.axf
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: arm-none-eabi-g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: error:
lto-wrapper failed
[...]
(https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/b/binutils-arm-none-eabi/20220621_090851_aa0ae@/log.gz)
The issue is that Ubuntu uses LTO by default *on amd64*, and the change to
include the output of dpkg-buildflags somehow has the effect that LTO is now
being used for the target.
This does not currently cause a problem in Debian because Debian is not
doing LTO by default; but there is discussion about changing this, so this
will likely become a problem in Debian as well within the current release
cycle.
One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
exclude the LTO flags specifically so that they don't leak into the target
builds. Another thought I had was to use the dpkg-buildflags for armhf as a
target architecture, since there could be other per-arch flags in the future
that cause further problems. I've tried the latter approach in the attached
patch, which fixes the problem of lto being incorrectly used for the
arm-none-eabi target. I've verified that the resulting libstdc++ is usable
again with this change.
Thanks for considering,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libstdc++-arm-none-eabi-20/debian/rules
libstdc++-arm-none-eabi-20ubuntu1/debian/rules
--- libstdc++-arm-none-eabi-20/debian/rules 2022-03-25 15:22:56.000000000
-0700
+++ libstdc++-arm-none-eabi-20ubuntu1/debian/rules 2022-07-08
12:25:35.000000000 -0700
@@ -12,6 +12,9 @@
include /usr/share/dpkg/pkg-info.mk
include /usr/share/dpkg/buildflags.mk
+CFLAGS := $(shell env DEB_HOST_ARCH=armhf dpkg-buildflags --get CFLAGS)
+CXXFLAGS := $(shell env DEB_HOST_ARCH=armhf dpkg-buildflags --get CXXFLAGS)
+
SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
DVERSION := $(SVERSION)+$(DEB_VERSION)
UVERSION := $(shell echo $(DVERSION) | cut -d- -f1)
