Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On Thu, Aug 18, 2022 at 12:13 AM Thorsten Glaser wrote: > > Arnd Bergmann dixit: > > >The way the FPU type gets selected in gcc changed with recent versions, > >this was intentional and won't be reverted but it did break packages that > >used the old method. > > Hmph. > > >In most cases, it's sufficient to pass > >-march=armv7-a+fp instead of -march=armv7-a to pick the right > >instruction set. > > There’s no “instead of”, though. > > So basically, I now need to add -march=… to CFLAGS in the package > when compiling for either of armel and armhf. What I see with gcc-12-arm-linux-gnueabihf 12.1.0-8cross1 is that it defaults to the correct architecture level (armv7-a+fp) and passes that to the assembler, so it /should/ not be necessary do this explictily. The problem with other packages was that they did pass "-march=armv7-a" for armhf, but that is interpreted as not having an FPU now, where on older compilers the -mhard-float flag would override the -march= flag and enable support for an FPU regardless. > Which value do I use for armel, which for armhf (the one you gave > is for armhf, I think)? That should be -march=armv5te Arnd
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >The way the FPU type gets selected in gcc changed with recent versions, >this was intentional and won't be reverted but it did break packages that >used the old method. Hmph. >In most cases, it's sufficient to pass >-march=armv7-a+fp instead of -march=armv7-a to pick the right >instruction set. There’s no “instead of”, though. So basically, I now need to add -march=… to CFLAGS in the package when compiling for either of armel and armhf. Which value do I use for armel, which for armhf (the one you gave is for armhf, I think)? bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1017537: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >I tried cross-building it myself now and found the same issue with >an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as > >/usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as >-v -march=armv7-a -mfloat-abi=hard -meabi=5 -o bin-arm/__longjmp.o >longjmp.s > >where the old one would pass an extra -mfpu=vfpv3-d16. Is my expectation that, for any given platform (armel, armhf, arm64), that a default invocation of the system compiler adds the correct flags not good? >However, with arm-linux-gnueabihf-gcc-12, it appears to work fine again. Sounds like a bug in gcc-11 instead then? (Why has this then not hit more packages?) >I also see that the Makefile attempts to detect the host architecture, but >fails to recognize armv8 hardware as arm. What hardware and toolchain >environment was the failing build on? debian/rules inspects DEB_HOST_ARCH and passes MYARCH to the upstream Makefile so this ought to DTRT…ish — arm64 is passed as aarch64, and all other *arm* are passed as arm (though we don’t carry armeb or the pre-EABI arm any more so that’s probably also fine). Note that #1017537 (on armel) and #1017538 (on armhf) probably are, if not the same thing, at least related. bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On Wed, Aug 17, 2022 at 8:00 PM Thorsten Glaser wrote: > > Arnd Bergmann dixit: > > >-march=armv7-a+fp instead of -march=armv7-a to pick the right > > “instead of” > > We pass nothing there, and we need a solution (or two distinct > ones) for armel and armhf. I tried cross-building it myself now and found the same issue with an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as /usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as -v -march=armv7-a -mfloat-abi=hard -meabi=5 -o bin-arm/__longjmp.o longjmp.s where the old one would pass an extra -mfpu=vfpv3-d16. However, with arm-linux-gnueabihf-gcc-12, it appears to work fine again. I also see that the Makefile attempts to detect the host architecture, but fails to recognize armv8 hardware as arm. What hardware and toolchain environment was the failing build on? Arnd
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On 2022-08-17 17:28:08 +, Thorsten Glaser wrote:
> tags 1017538 + help
> forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
> thanks
>
> Hi Sebastian,
>
> instead of filing a bug with the information we already have…
>
> >arm/__longjmp.S: Assembler messages:
> >arm/__longjmp.S:9: Error: selected processor does not support `vldm
> >ip!,{d0-d15}' in ARM mode
>
> … you could maybe have considered answering the question I posed
> on the Debian ARM mailing list about *why* it fails because nothing
> related to ARM was changed in the package or code.
Don't shoot the messanger.
Cheers
>
> So something in the toolchain(?) must have changed since the last
> successful build (what?) which we need to locally revert.
>
> Thanks in advance for any help,
> //mirabilos
> --
> Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
> schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
> Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
> hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
--
Sebastian Ramacher
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >-march=armv7-a+fp instead of -march=armv7-a to pick the right “instead of” We pass nothing there, and we need a solution (or two distinct ones) for armel and armhf. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
On Wed, Aug 17, 2022 at 7:28 PM Thorsten Glaser wrote:
>
> tags 1017538 + help
> forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
> thanks
>
> Hi Sebastian,
>
> instead of filing a bug with the information we already have…
>
> >arm/__longjmp.S: Assembler messages:
> >arm/__longjmp.S:9: Error: selected processor does not support `vldm
> >ip!,{d0-d15}' in ARM mode
>
> … you could maybe have considered answering the question I posed
> on the Debian ARM mailing list about *why* it fails because nothing
> related to ARM was changed in the package or code.
>
> So something in the toolchain(?) must have changed since the last
> successful build (what?) which we need to locally revert.
The way the FPU type gets selected in gcc changed with recent versions,
this was intentional and won't be reverted but it did break packages that
used the old method. In most cases, it's sufficient to pass
-march=armv7-a+fp instead of -march=armv7-a to pick the right
instruction set.
Arnd
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
tags 1017538 + help
forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
thanks
Hi Sebastian,
instead of filing a bug with the information we already have…
>arm/__longjmp.S: Assembler messages:
>arm/__longjmp.S:9: Error: selected processor does not support `vldm
>ip!,{d0-d15}' in ARM mode
… you could maybe have considered answering the question I posed
on the Debian ARM mailing list about *why* it fails because nothing
related to ARM was changed in the package or code.
So something in the toolchain(?) must have changed since the last
successful build (what?) which we need to locally revert.
Thanks in advance for any help,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Source: dietlibc
Version: 0.34~cvs20160606-14
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=dietlibc=armhf=0.34%7Ecvs20160606-14=1658252860=0
arm/__longjmp.S: Assembler messages:
arm/__longjmp.S:9: Error: selected processor does not support `vldm
ip!,{d0-d15}' in ARM mode
make[2]: *** [Makefile:206: bin-arm/__longjmp.o] Error 1
make[2]: *** Waiting for unfinished jobs
: -x -R .comment -R .note bin-arm/realpath.o
: -x -R .comment -R .note bin-arm/fnmatch.o
: -x -R .comment -R .note bin-arm/glob.o
: -x -R .comment -R .note bin-arm/sha256crypt.o
: -x -R .comment -R .note bin-arm/rx.o
: -x -R .comment -R .note bin-arm/sha512crypt.o
make[2]: Leaving directory '/<>'
dh_auto_build: error: make -j8 "INSTALL=install --strip-program=true"
prefix=/usr/lib/arm-linux-gnueabihf/diet MYARCH=arm
VERSION=0.34\~cvs20160606-14 DEBUG=1 "CFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 -g
-O2 -ffile-prefix-map=/<>=.
-specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wall -fno-pie -specs=/usr/share/dpkg/no-pie-link.specs
-Wl,-z,relro -Wl,-z,now -no-pie -pipe -nostdinc -D_REENTRANT -Os
-fomit-frame-pointer -fstrict-aliasing -W -Wall -Wextra -Wchar-subscripts
-Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused
-Wredundant-decls -Wshadow" returned exit code 2
make[1]: *** [debian/rules:94: override_dh_auto_build-arch] Error 25
Cheers
--
Sebastian Ramacher
