Date: Mon, 30 May 2016 21:19:54 -0700 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD Current <freebsd-current@freebsd.org>, Bryan Drewery <bdrewery@FreeBSD.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use] Message-ID: <311011FA-F5B0-499D-AE47-31D430257A8A@dsl-only.net> In-Reply-To: <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net> References: <8A197698-51C7-43F9-9927-465602E19AAE@dsl-only.net> <C0ABC879-468D-4C78-8DEC-3A6F41D7ECB4@dsl-only.net> <137F75C8-F81A-44EE-B036-D7ABA7C75684@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.]
>=20
> On 2016-May-29, at 11:32 PM, Mark Millard <markmi at dsl-only.net> =
wrote:
>=20
>> [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.]
>>=20
>> The failure:
>>=20
>>> --- 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
>>>=20
>>> make[4]: stopped in /usr/src/lib/libc
>>> 1 error
>>>=20
>>> make[4]: stopped in /usr/src/lib/libc
>>> *** [lib/libc__L] Error code 2
>>=20
>> Note the /usr/bin/ld use: the host (amd64) linker for a powerpc link =
operation.
>>=20
>> The log shows the ld command was via clang=E2=80=99s front end as far =
as what the build did directly (just a prefix shown):
>>=20
>>> --- libc.so.7.full ---
>>> /usr/bin/clang -target powerpc-unknown-freebsd11.0 =
--sysroot=3D/usr/obj/clang/powerpc.powerpc/usr/src/tmp =
-B/usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/bin -nodefaultlibs =
-Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings =
-Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 =
`NM=3D'nm' NMFLAGS=3D'' 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
>> . . .
>>=20
>> The -B does not point to a place with a powerpc specific ld command:
>>=20
>>> # 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
>>=20
>> As far as I can tell a potentially proper path would have been:
>>=20
>> /usr/local/powerpc-freebsd/bin/ld
>>=20
>> if a devel/powerpc-binutils port existed and was installed. (No such =
port exists.)
>>=20
>> I do not know if other TARGET_ARCH=E2=80=99s have similar problems or =
not (even if they have a binutils port).
>>=20
>>=20
>> This was not a WITH_META_MODE=3Dyes context.
>>=20
>>=20
>> make.conf was empty and src.conf was:
>>=20
>> TO_TYPE=3Dpowerpc
>> #
>> KERNCONF=3DGENERICvtsc-NODEBUG
>> TARGET=3D${TO_TYPE}
>> .if ${.MAKE.LEVEL} =3D=3D 0
>> TARGET_ARCH=3D${TO_TYPE}
>> .export TARGET_ARCH
>> .endif
>> #
>> WITHOUT_CROSS_COMPILER=3D
>> WITH_SYSTEM_COMPILER=3D
>> #
>> WITH_LIBCPLUSPLUS=3D
>> WITH_BINUTILS_BOOTSTRAP=3D
>> WITH_CLANG=3D
>> WITH_CLANG_IS_CC=3D
>> WITH_CLANG_FULL=3D
>> WITH_CLANG_EXTRAS=3D
>> # lldb requires missing atomic 8-byte operations for powerpc (non-64)
>> WITHOUT_LLDB=3D
>> #
>> WITH_BOOT=3D
>> WITHOUT_LIB32=3D
>> #
>> WITHOUT_GCC_BOOTSTRAP=3D
>> WITHOUT_GCC=3D
>> WITHOUT_GCC_IS_CC=3D
>> WITHOUT_GNUCXX=3D
>> #
>> NO_WERROR=3D
>> #WERROR=3D
>> MALLOC_PRODUCTION=3D
>> #
>> WITH_DEBUG_FILES=3D
>>=20
>>=20
>> =3D=3D=3D
>> Mark Millard
>> markmi at dsl-only.net
>=20
> I finally tried a amd64 host -> armv6 (rpi2) cross build for freebsd =
11.0.
>=20
> 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.
>=20
> 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].)
>=20
> 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.
>=20
> 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?)
>=20
>=20
> I'm not sure if the following additional item is a potential issue or =
not:
>=20
> 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?)
>=20
>=20
>=20
> =3D=3D=3D
> 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) =46rom 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.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?311011FA-F5B0-499D-AE47-31D430257A8A>