Date: Sat, 2 May 2020 15:52:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: Emmanuel Vadot <manu@freebsd.org>, svn-ports-head@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: svn commit: r533381 - head/devel/aarch64-none-elf-gcc Message-ID: <F281FD58-F654-410E-90C9-931A5C3B6468@yahoo.com> In-Reply-To: <CDFD1AF1-E96B-417B-AFA8-81E0DC31DD3E@yahoo.com>
index | next in thread | previous in thread | raw e-mail
[Correcting an omission.] > On 2020-May-2, at 15:26, Mark Millard <marklmi at yahoo.com> wrote: > >> Author: manu >> Date: Wed Apr 29 17:17:52 2020 >> New Revision: 533381 >> URL: >> https://svnweb.freebsd.org/changeset/ports/533381 >> >> >> Log: >> devel/aarch64-none-elf-gcc: Fix building plugins >> >> For building plugins gcc needs objdump, whcih exists in amd64 world but >> not on aarch64. We already have a dependancy on devel/binutils but this >> port install binaries in ${LOCALBASE}/${GCC_TARGET}/bin so add that to >> the PATH. >> >> Reported by: Mark Millard >> >> Modified: >> head/devel/aarch64-none-elf-gcc/Makefile >> >> Modified: head/devel/aarch64-none-elf-gcc/Makefile >> ============================================================================== >> --- head/devel/aarch64-none-elf-gcc/Makefile Wed Apr 29 16:07:00 2020 (r533380) >> +++ head/devel/aarch64-none-elf-gcc/Makefile Wed Apr 29 17:17:52 2020 (r533381) >> @@ -46,6 +46,8 @@ CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls - >> --with-as=${LOCALBASE}/bin/${GCC_TARGET}-as \ >> --with-ld=${LOCALBASE}/bin/${GCC_TARGET}-ld >> >> +MAKE_ENV+= PATH=${PATH}:${LOCALBASE}/${GCC_TARGET}/bin >> + > . . . > > ${LOCALBASE}/${GCC_TARGET}/bin is not appropriate to all uses of > this Makefile : the contained objdump does not handle all the > file formats that the cross build tries to use > ${LOCALBASE}/${GCC_TARGET}/bin/objdump for: > > ${LOCALBASE}/arm-none-eabi/bin/objdump does not handle "ARM aarch64, > version 1 (FreeBSD)", even on an aarch64 system. > > ${LOCALBASE}/aarch64-none-elf/bin/objdump does not handle "ARM, EABI5 > version 1 (FreeBSD)", even on a armv7 system. > > By contrast, devel/binutils@native handles the system's file format > just fine in all cases where the build attempts its use. > > The builds are trying (in part) to have the system use the objdump > that is inappropriate for what the build is attempting to do. > > I'll list evidence for each case, first aarch64 vs. arm-none-eabi. > > > > aarch64 systen vs. /usr/local/arm-none-eabi/bin/objdump use . . . > > On aarch64 (Rock64) for GCC_TARGET being arm-none-eabi > for working with arm-none-eabi tools the objdump does > not even recognize its own format: > > /usr/local/arm-none-eabi/bin/objdump -a /usr/local/arm-none-eabi/bin/objdump > /usr/local/arm-none-eabi/bin/objdump: /usr/local/arm-none-eabi/bin/objdump: file format not recognized > > This is because: > > file /usr/local/arm-none-eabi/bin/objdump > /usr/local/arm-none-eabi/bin/objdump: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300092), FreeBSD-style, with debug_info, not stripped > > but /usr/local/arm-none-eabi/bin/objdump does not handle the > ARM aarch64, version 1 (FreeBSD) format. > > The build is attempting to use the /usr/local/arm-none-eabi/bin/objdump > on "ARM aarch64, version 1 (FreeBSD)" files and is getting the "file > format not recognized" notice. It needs "objdump" to find a version > that does handle the format. > > > > > armv7 system vs. /usr/local/aarch64-none-elf/bin/objdump use . . . > > On armv7 (OPi+2e) for GCC_TARGET being aarch64-none-elf > for working with aarch64-none-elf tools the objdump does > not even recognize its own format: > > # /usr/local/aarch64-none-elf/bin/objdump -a /usr/local/aarch64-none-elf/bin/objdump > > /usr/local/aarch64-none-elf/bin/objdump: file format elf32-littlearm > /usr/local/aarch64-none-elf/bin/objdump > > This is because: > > # file /usr/local/aarch64-none-elf/bin/objdump > /usr/local/aarch64-none-elf/bin/objdump: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.0 (1300082), FreeBSD-style, stripped > > but /usr/local/aarch64-none-elf/bin/objdump does not handle the > ARM, EABI5 version 1 (FreeBSD) format. > > The build is attempting to use the /usr/local/aarch64-none-elf/bin/objdump > on "ARM, EABI5 version 1 (FreeBSD)" files and is getting the "file format > not recognized" notice. It needs "objdump" to find a version > that does handle the format. > > > > I'll note that, as far as I can tell, when the build wants to > use aarch64-none-elf/bin/objdump or arm-none-eabi/bin/objdump > it explicitly uses a path to the special variant instead of > being PATH dependent. > > > My suggestion is the patch that I originally reported on > the lists: > > -BUILD_DEPENDS= ${GCC_TARGET}-as:devel/binutils@${PKGNAMEPREFIX:C/-$//:C/-/_/g} > +BUILD_DEPENDS= ${GCC_TARGET}-as:devel/binutils@${PKGNAMEPREFIX:C/-$//:C/-/_/g} \ > + objdump:devel/binutils > > This has worked in all my poudriere-devel based testing > so far: > > I've been able to build the following in an armv7 > context despite it needing to build and use both > aarch64-none-elf and arm-none-eabi materials: > > Finished devel/aarch64-none-elf-gcc | aarch64-none-elf-gcc-8.4.0_1: Success > Finished sysutils/rpi-firmware | rpi-firmware-1.20190925.g20200109: Success > Finished devel/arm-none-eabi-gcc | arm-none-eabi-gcc-8.4.0_1: Success > Finished sysutils/u-boot-rpi2 | u-boot-rpi2-2020.04: Success > Finished sysutils/u-boot-orangepi-plus-2e | u-boot-orangepi-plus-2e-2020.04: Success > Finished sysutils/u-boot-sinovoip-bpi-m3 | u-boot-sinovoip-bpi-m3-2020.04: Success > > (I do not normally have armv7 build aarch64 material but do have > aarch64 build both aarch64 and armv7 materials.) > > Similarly I've been able to build those in an aarch64 > context, as well as building: > > Finished sysutils/atf-rk3328 | atf-rk3328-v2.3: Success > Finished sysutils/atf-sun50i_a64 | atf-sun50i_a64-v2.3: Success > Finished sysutils/u-boot-rpi4 | u-boot-rpi4-2020.04: Success > Finished sysutils/u-boot-rpi3 | u-boot-rpi3-2020.04: Success > Finished sysutils/u-boot-rock64 | u-boot-rock64-2020.04: Success > Finished sysutils/u-boot-pine64 | u-boot-pine64-2020.04: Success > > Such is not true when attempted with -r533381 . > > (Note: I really specified to build the u-boot-*'s and the > others were built via dependencies.) I should have also indicated that I explicitly request sysutils/rpi-firmware to be built, not just the sysutils/u-boot-*'s. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F281FD58-F654-410E-90C9-931A5C3B6468>