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
>> #
>> .if ${.MAKE.LEVEL} == 0
>> .export TARGET_ARCH
>> .endif
>> #
>> #
>> # lldb requires missing atomic 8-byte operations for powerpc (non-64)
>> #
>> #
>> #
>> #
>> ===
>> 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 

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 

Mark Millard
markmi at dsl-only.net

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to