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.netReceived on Tue May 31 2016 - 02:20:02 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:05 UTC