11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use]
Mark Millard
markmi at dsl-only.net
Tue May 31 04:20:02 UTC 2016
On 2016-May-30, at 5:40 PM, Mark Millard <markmi at dsl-only.net> wrote:
> [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
I looked around some more and I think I've found one or two points missed in some of the WITH_SYSTEM_COMPILER coverage. Such may explain part of the above.
A) The bootstrap clang compiler is built to automatically use the WITH_BINUTILS_BOOTSTRAP instances of the binutils if I understand right.
B) The system clang compiler is not. So, for example, it by default uses /usr/bin/ld as the linker.
C) From what I've seen WITH_SYSTEM_COMPILER for cross-builds is not building the WITH_BINUTILS_BOOTSTRAP binutils (and so is not putting the them in a place that it would use via -B, which might then manage to redirect the system clang to find those WITH_BINUTILS_BOOTSTRAP binutils).
D) This may get odder when hardfloat vs. libsoft is considered: what tools need to be different tool instances for building libsoft? Are the armv6-gnueabihf-freebsd11.0 related tools sufficient to cover armv6-gnueabi-freebsd11.0 (libsoft's softfloat) without switching to any other tool(s)?
Side note:
There is also another difference [this just mentions some material from another, later report that I made on the lists]:
E) The bootstrap clang compilers/cpp does not need -target and allows selection of -march from the target family and tracks when such is done. But there are contexts that still assume this status when WITH_SYSTEM_COMPILER is in use but the system compiler does not have this property for cross-build usage. The examples that I've noticed are tied to building libsoft. An appropriate -target is always needed, potentially even for clang-cpp to have the fully correct behavior.
===
Mark Millard
markmi at dsl-only.net
More information about the freebsd-toolchain
mailing list