11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use]

[This adds armv6 information to a prior note that was just powerpc based. The powerpc example material is listed first then it is noted that armv6 ended up similar in my attempt.]

On 2016-May-29, at 11:32 PM, Mark Millard <markmi at dsl-only.net> wrote:

> [It may well be that powerpc is not an intended cross compile target via clang since clang is insufficient for an FreeBSD/powerpc ABI compliant buildworld as stands. Still I use this to illustrate the more general points for clang use in cross builds.]
> 
> The failure:
> 
>> --- libc.so.7.full ---
>> /usr/bin/ld: unrecognised emulation mode: elf32ppc_fbsd
>> Supported emulations: elf_x86_64_fbsd elf_i386_fbsd
>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>> *** [libc.so.7.full] Error code 1
>> 
>> make[4]: stopped in /usr/src/lib/libc
>> 1 error
>> 
>> make[4]: stopped in /usr/src/lib/libc
>> *** [lib/libc__L] Error code 2
> 
> Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link operation.
> 
> The log shows the ld command was via clang’s front end as far as what the build did directly (just a prefix shown):
> 
>> --- libc.so.7.full ---
>> /usr/bin/clang -target powerpc-unknown-freebsd11.0 --sysroot=/usr/obj/clang/powerpc.powerpc/usr/src/tmp -B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin  -nodefaultlibs -Wl,--version-script=Version.map  -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o libc.so.7.full -Wl,-soname,libc.so.7  `NM='nm' NMFLAGS='' lorder trivial-vdso_tc.So bt_close.So bt_conv.So bt_debug.So bt_delete.So bt_get.So bt_open.So bt_overflow.So bt_page.So
> . . .
> 
> The -B does not point to a place with a powerpc specific ld command:
> 
>> # ls -lt /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin
>> total 1395
>> -rwxr-xr-x   1 root  wheel  827248 May 29 22:20 ctfmerge
>> -rwxr-xr-x   1 root  wheel  534712 May 29 22:20 sysinit
>> -rwxr-xr-x   1 root  wheel  960784 May 29 22:20 ctfconvert
> 
> As far as I can tell a potentially proper path would have been:
> 
> /usr/local/powerpc-freebsd/bin/ld
> 
> if a devel/powerpc-binutils port existed and was installed. (No such port exists.)
> 
> I do not know if other TARGET_ARCH’s have similar problems or not (even if they have a binutils port).
> 
> 
> This was not a WITH_META_MODE=yes context.
> 
> 
> make.conf was empty and src.conf was:
> 
> TO_TYPE=powerpc
> #
> KERNCONF=GENERICvtsc-NODEBUG
> TARGET=${TO_TYPE}
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITHOUT_CROSS_COMPILER=
> WITH_SYSTEM_COMPILER=
> #
> WITH_LIBCPLUSPLUS=
> WITH_BINUTILS_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> # lldb requires missing atomic 8-byte operations for powerpc (non-64)
> WITHOUT_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG_FILES=
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

I finally tried a amd64 host -> armv6 (rpi2) cross build for freebsd 11.0.

amd64 -> armv6 for freebsd 11.0 also ended up with linker vs. file format/content mismatches: in this case what was reported was about the crti.o format when attempting to link libc.so.7.full . The error messages were not explicit about the linker path used, unfortunately. .../tmp/usr/bin as listed in the -B had only the same 3 file names (and no ld) as was shown above for the powerpc context.

Again it is a context of using the clang front end to indirectly get to the linker with "-target" needing to guide details if the selection of the linker is to be automatic. (Otherwise -B likely needs to point to where an appropriate tool set is to be found [including ld].)

armv6 for freebsd 11.0 is likely intended to be supported, unlike powerpc possibly being viewed as irrelevant currently because of clang's code generation issues for powerpc variants.

armv6-gnueabihf-freebsd11.0 for modern hardfloat vs. armv6-gnueabi-freebsd11.0 for temporary softfloat may need distinct linkers (or other tools)? (Possibly via distinct -B's?)


I'm not sure if the following additional item is a potential issue or not:

While there is a devel/arm-gnueabi-binutils there is no devel/arm-gnueabihf-binutils. But I notice that -target armv6-gnueabihf-freebsd11.0 is in use now for freebsd 11.0. Targets of the form armv6-gnueabi-freebsd10* are probably still needed to support 10.x for rpi's and the like. (So is another port needed?)



===
Mark Millard
markmi at dsl-only.net