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

Sat May 2 22:26:26 UTC 2020

> 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.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)