cross-arm-none-eabi/newlib-4.3.0.20230120::crossdev failed (compile phase): emake failed Reproducible: Always emerge --info cross-arm-none-eabi/newlib Portage 3.0.44 (python 3.10.9-final-0, default/linux/amd64/17.1/desktop, gcc-11, glibc-2.36-r6, 6.1.7-gentoo-x86_64 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-6.1.7-gentoo-x86_64-x86_64-Intel-R-_Core-TM-_i7-4770K_CPU_@_3.50GHz-with-glibc2.36 KiB Mem: 7815796 total, 3938520 free KiB Swap: 8388604 total, 8388604 free Timestamp of repository gentoo: Sat, 21 Jan 2023 10:46:58 +0000 Head commit of repository gentoo: c1a1cd42efcaebaa04c37733f5c7ec35dd1b9ec6 sh bash 5.2_p15-r1 ld GNU ld (Gentoo 2.39 p5) 2.39.0 distcc 3.4 x86_64-pc-linux-gnu [disabled] ccache version 4.7.4 [disabled] app-misc/pax-utils: 1.3.5::gentoo app-shells/bash: 5.2_p15-r1::gentoo dev-lang/perl: 5.36.0-r1::gentoo dev-lang/python: 3.10.9::gentoo, 3.11.1::gentoo dev-lang/rust: 1.66.1::gentoo dev-util/ccache: 4.7.4::gentoo dev-util/cmake: 3.25.2::gentoo dev-util/meson: 0.64.1::gentoo sys-apps/baselayout: 2.9::gentoo sys-apps/openrc: 0.45.2-r2::gentoo sys-apps/sandbox: 2.29::gentoo sys-devel/autoconf: 2.13-r7::gentoo, 2.71-r5::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.39-r4::gentoo sys-devel/binutils-config: 5.4.1::gentoo sys-devel/clang: 15.0.6-r1::gentoo sys-devel/gcc: 11.3.1_p20221209::gentoo sys-devel/gcc-config: 2.10::gentoo sys-devel/libtool: 2.4.7::gentoo sys-devel/llvm: 15.0.6-r1::gentoo sys-devel/make: 4.4::gentoo sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.36-r6::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo sync-user: portage:portage priority: -1000 volatile: True sync-git-verify-commit-signature: true crossdev location: /var/db/repos/crossdev masters: gentoo volatile: True local location: /var/db/repos/local masters: gentoo priority: 1000 volatile: True ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* @FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/grs/systems.conf /etc/stunnel/stunnel.conf /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-march=native -O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-march=native -O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" MAKEOPTS="-j4" PKGDIR="/var/cache/binpkgs" PORTAGE_BZIP2_COMMAND="/bin/bzip2" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X a52 aac acl acpi alsa amd64 bluetooth branding bzip2 cairo cdda cdr cli crypt cups dbus dri dts dvd dvdr elogind emacs encode exif flac fortran gdbm gif gles2 gnome-keyring gpm gtk gui iconv icu imagemagick ipv6 jpeg lcms libglvnd libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf perl png policykit ppds pulseaudio qt5 readline sdl seccomp sound spell split-usr ssl startup-notification svg test-rust tiff tk truetype udev udisks unicode upower usb vaapi vim-syntax vorbis wxwidgets x264 xattr xcb xft xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt rdrand sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc efi-64 efi-32" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="BPF" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_10" PYTHON_TARGETS="python3_10" QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64 arm" RUBY_TARGETS="ruby30" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS ================================================================= Package Settings ================================================================= cross-arm-none-eabi/newlib-4.2.0.20211231::crossdev was built with the following: USE="nano nls unicode -headers-only -threads" ABI_X86="(64)" CFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" LDFLAGS=""
Created attachment 848909 [details] Build log
I can confirm the issue
It seems to be a newlib issue, caused by a recent commit[1]. I suspect the macro-definitions tests around `vstm`/vldm` are incorrect... probably there supposed to be AND (`#if defined __ARM_FP && defined __ARM_FEATURE_MVE`) rather than OR (`||`)... though I'm not absolutely positive about that... it might be there supposed to be some `#else` in case `__ARM_FEATURE_MVE` is undefined (and as I suppose in such case the instruction are unavailable)... [1]: https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;f=newlib/libc/machine/arm/setjmp.S;h=15ad816dddf836def06cd0330ec0efa9ce50e5bf
it builds fine for me with: cross-arm-eabi/binutils-2.39-r4 cross-arm-eabi/gcc-12.2.1_p20221231 cross-arm-eabi/newlib-4.3.0.20230120 what version of tools are you using ?
(In reply to SpanKY from comment #4) > it builds fine for me with: > cross-arm-eabi/binutils-2.39-r4 > cross-arm-eabi/gcc-12.2.1_p20221231 > cross-arm-eabi/newlib-4.3.0.20230120 > > what version of tools are you using ? cross-arm-none-eabi/gcc-11.3.1_p20221209 cross-arm-none-eabi/binutils-2.39-r4 sys-devel/gcc-11.3.1_p20221223 (amd64 host) cross-arm-none-eabi/newlib-4.3.0.20230120 (fail, as for the bug) cross-arm-none-eabi/newlib-4.2.0.20211231 (compiles fine)
Builds fine with cross-arm-none-eabi/gcc-12.2.1_p20221231 for me as well... So it seems to me it's a gcc-11 issue...
Ok... I've poked it a bit more... here is what I've boiled it down to: gcc<12 (at least since 8) with flags like `-march=armv5te+fp -mfloat-abi=softfp` will refuse to compile arm FPU assembler instructions unless explicitly given an `-mfpu=auto` flag... That's only an issue for ASM code... C sources are unaffected because when assembled explicit `.fpu vfp` directive is added to the output... I failed to found any discussion/bugs/commits regarding that issue in gcc. I'm not sure how properly fix/workaround the issue... The simplest IMHO would be to nail newlib-4.3.0.20230120 to gcc-12+ on arm... Also I've managed to workaround it setting CCASFLAGS="-mfpu=auto" env var, though it's a bit of a dirty way to do it...
PS: As of my previous idea about incorrect preprocessor macros: I was wrong.
(In reply to Fat-Zer from comment #7) there is no way to do arch-specific DEPENDs i don't think upstream intended to make this requirement, and in general doesn't want to force recent versions of gcc. i can point out the problem on the patch and see what they say.
(In reply to SpanKY from comment #9) > (In reply to Fat-Zer from comment #7) > > there is no way to do arch-specific DEPENDs Yeah... I was thinking we can die on pkg-setup like it's done for msp430/bug #717610... or if a failure sounds too much we can at least print a stern warning... > i don't think upstream intended to make this requirement, and in general doesn't want to force recent versions of gcc. i can point out the problem on the patch and see what they say. sure they don't... it looks like a gcc quirk...
I've now proposed a Newlib patch to address the issue: https://sourceware.org/pipermail/newlib/2023/020154.html I've tested it going as far back as GCC 10.1 and I get a successful build with it, so I hope this serves as an adequate solution.
(In reply to Victor Do Nascimento from comment #11) > I've now proposed a Newlib patch to address the issue: > > https://sourceware.org/pipermail/newlib/2023/020154.html > > I've tested it going as far back as GCC 10.1 and I get a successful build > with it, so I hope this serves as an adequate solution. Are you sure hardcoding an .fpu directive is safe enough for people targeting a different FPU and/or explicitly specifying it during build? I don't know that much about arm FPUs and how diverse they and their instruction sets are, so I'm a bit concern that there might be some build breakages (or even generation of malformed binaries) in such cases... though it might be alright...
(In reply to Fat-Zer from comment #12) > (In reply to Victor Do Nascimento from comment #11) > > I've now proposed a Newlib patch to address the issue: > > > > https://sourceware.org/pipermail/newlib/2023/020154.html > > > > I've tested it going as far back as GCC 10.1 and I get a successful build > > with it, so I hope this serves as an adequate solution. > > Are you sure hardcoding an .fpu directive is safe enough for people > targeting a different FPU and/or explicitly specifying it during build? I > don't know that much about arm FPUs and how diverse they and their > instruction sets are, so I'm a bit concern that there might be some build > breakages (or even generation of malformed binaries) in such cases... though > it might be alright... If you look at the FPU-related instructions used in the file in question (setjmp.S), you'll see we do very little w/ the FPUs. The only operations concerned are those saving register values to memory and restoring them some time later using vstm and vldm. Insofar as the encodings for these instructions go, if you look at the ARM Architectural Reference Manuals, you'll see that the The encoding of an FP extension register load or store instructions makes no reference to the FPU used and is therefore invariant over the FPU choice. When it comes to linking, we need to be careful over the build attributes which get added to the resulting object as a result of or `.fpu name' choice. `.fpu vfpxd' seems to be a type of "lowest-common denominator" allowing us greatest flexibility when linking. From what I understand, vfpxd corresponds to FPU_ARCH_VFP_V1xD in the assembler, which is VFPv1 w/o support for doubles. We're not adding any attribute to our assembled setjmp/longjump functions which would suggest they require any architectural feature that vfp/mve targets can't provide, such that whatever target we're compiling for we shouldn't experience any linking difficulty. The now-committed fix to the issue also adds `.arch_extension mve' to the assembly file whenever we target MVE, hopefully covering all our bases.
(In reply to Victor Do Nascimento from comment #13) > ... Thanks for the explanation, everything you say sounds legit... For the record, I was voicing my concern just because of a doubt (which I've supposed was reasonable enough); before posting I was inclining to the same conclusions you have listed, but I wasn't sure enough... PS: As for now, I think, the right resolution for the Gentoo bug (if my opinion worths anything) would be to backport the patch.
Thanks for the feedback, I'm glad my reasoning seems reasonable! I will chase the Newlib maintainers about having the patch backported to newlib-4.3.
A new snapshot of Newlib can be made, which would include the fix for this bug. The maintainers are waiting on the fix of a different unrelated issue so that the new snapshot can kill two birds in one stone. How urgent is the backport? Depending on the timeframe you've got in mind, I can liaise with the relevant parties in search of a satisfactory solution for everyone.
(In reply to Victor Do Nascimento from comment #16) > A new snapshot of Newlib can be made, which would include the fix for this > bug. > > The maintainers are waiting on the fix of a different unrelated issue so > that the new snapshot can kill two birds in one stone. Any idea how that issue is going? We can wait if it's a little bit longer, but I wouldn't want to wait months either, I suppose. > > How urgent is the backport? Depending on the timeframe you've got in mind, I > can liaise with the relevant parties in search of a satisfactory solution > for everyone. Thank you.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d2ff0e8d3c0e012ed57743adb869797782f1a26 commit 1d2ff0e8d3c0e012ed57743adb869797782f1a26 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-17 02:58:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-06-17 02:58:41 +0000 sys-libs/newlib: backport arm setjmp fix It looked like a new upstream release/snapshot was going to be made so I'd forgot about it, but got reminded of this today, so let's backport the patch. Closes: https://bugs.gentoo.org/891589 Signed-off-by: Sam James <sam@gentoo.org> ...0120-libc-arm-setjmp-gcc-backwards-compat.patch | 57 ++++++++ sys-libs/newlib/newlib-4.3.0.20230120-r2.ebuild | 154 +++++++++++++++++++++ 2 files changed, 211 insertions(+)
