svn commit: r533381 - head/devel/aarch64-none-elf-gcc

Sat May 2 22:52:13 UTC 2020

[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 at 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)