svn commit: r533381 - head/devel/aarch64-none-elf-gcc
Mark Millard
marklmi at yahoo.com
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)
More information about the freebsd-arm
mailing list