Date: Mon, 24 Jul 2017 00:33:16 -0700 From: Mark Millard <markmi@dsl-only.net> To: Dimitry Andric <dim@FreeBSD.org> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: -r321371 amd64 -> powerpc64 cross build: lldb.full link fails with: c++: error: linker command failed with exit code 1, -B/usr/local/powerpc64-freebsd/bin/ in use Message-ID: <3E5E8DE4-0135-4071-A041-F56DB53EE3F3@dsl-only.net> In-Reply-To: <D5A9EC60-C832-498D-B29E-C96EDB990684@dsl-only.net> References: <9EF818CD-73FC-4283-8CC2-4BA21342CFB1@dsl-only.net> <98DFB763-0CA4-45B3-98E3-050462A9EC15@dsl-only.net> <FEB83F55-C486-487B-BC18-70F9DBF149F0@dsl-only.net> <B6B47C09-DC41-4170-A6E8-F5CC1C41B74D@FreeBSD.org> <9D2961AE-D423-4ED4-B16D-308BA19AC7A0@dsl-only.net> <B0EC1A43-FF42-4390-A21F-2066FC6E09CD@dsl-only.net> <BC420388-C2A9-4B6D-AB44-309FF900D935@dsl-only.net> <D5A9EC60-C832-498D-B29E-C96EDB990684@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I forgot that linking lldb historically failed on armv6 (cortex-a7) based on the historical system binutils.] On 2017-Jul-23, at 8:51 PM, Mark Millard <markmi@dsl-only.net> wrote: > [Using WITH_LLDB=3D had no problem for amd64 -> TARGET_ARCH=3Daarch64 > buildworld buildkernel .] >=20 > On 2017-Jul-23, at 3:44 PM, Mark Millard <markmi@dsl-only.net> wrote: >=20 >> [WITH_LLD=3D WITHOUT_LLDB=3D did a buildworld buildkernel >> just fine for TARGET_ARCH=3Dpowerpc64 .] >>=20 >> On 2017-Jul-23, at 2:46 PM, Mark Millard <markmi@dsl-only.net> wrote: >>=20 >>> [Shawn Webb's logfile shows an error similar to what I >>> report: lldb_private::AppleObjCRuntime::GetFoundationVersion() >>> is a problem. But his report shows other errors as well, ones >>> that I did not get.] >>>=20 >>> On 2017-Jul-23, at 1:04 PM, Mark Millard <markmi at dsl-only.net> = wrote: >>>=20 >>>> [The lldb problem is a: >>>>=20 >>>> lldb_private::AppleObjCRuntime::GetFoundationVersion() >>>>=20 >>>> reference via Cocoa.o in liblldb.a . See below. >>>> Sorry that sometimes I'm having to go back and >>>> later find and report more details because of >>>> other things going on here. But this likely >>>> will continue for some of my preliminary >>>> reports.] >>>>=20 >>>> On 2017-Jul-23, at 5:00 AM, Dimitry Andric <dim@FreeBSD.org> wrote: >>>>=20 >>>>> On 23 Jul 2017, at 11:17, Mark Millard <markmi@dsl-only.net> = wrote: >>>>>>=20 >>>>>> [Linking lldb.full via 2.28 of = /usr/local/powerpc64-freebsd/bin/ld >>>>>> also fails with "exit code 1" (using WIHTOUT_LLD so it gets that >>>>>> far). I'll continue via WITHOUT_LLDB.] >>>>> ... >>>>>>=20 >>>>>> Here is the lldb.full failure text: >>>>>>=20 >>>>>> --- all_subdir_usr.bin --- >>>>>> --- all_subdir_usr.bin/clang/lldb --- >>>>>> c++: error: linker command failed with exit code 1 (use -v to see = invocation) >>>>>=20 >>>>> Unfortunately the actual linker errors were above these lines, so = you >>>>> will have to look them up in the full build log (search for = "undefined >>>>> symbol"), or post that somewhere off-list. >>>>>=20 >>>>> I'm suspecting you get the same type of error Shawn's been getting = while >>>>> linking lldb. Apparently in some scenarios more object files are = needed >>>>> than the minimum set I put in liblldb's Makefile. >>>>=20 >>>> --- lldb.full --- >>>> = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/cla= ng/liblldb/liblldb.a(Cocoa.o): In function = `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObje= ct&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': >>>> = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.= text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObj= ectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): undefined reference = to `lldb_private::AppleObjCRuntime::GetFoundationVersion()' >>>=20 >>> The first error in Shawn Webb's logfile looks like what I report: >>>=20 >>> error: undefined symbol: = lldb_private::AppleObjCRuntime::GetFoundationVersion() >>>=20 >>> via Cocoa.o in liblldb.a . See below: >>>=20 >>> =3D=3D=3D> usr.sbin/ancontrol (all) >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: = lldb_private::AppleObjCRuntime::GetFoundationVersion() >>>>>> referenced by = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp >>>>>> = Cocoa.o:(lldb_private::formatters::NSNumberSummaryProvider(lldb_private::V= alueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions = const&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a >>>=20 >>> After that his log showed: >>>=20 >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: = lldb::SBTrace::SBTrace() >>>>>> referenced by = /usr/src/contrib/llvm/tools/lldb/source/API/SBProcess.cpp >>>>>> = SBProcess.o:(lldb::SBProcess::StartTrace(lldb::SBTraceOptions&, = lldb::SBError&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: = lldb::SBTrace::SetSP(std::__1::shared_ptr<lldb_private::Process> const&) >>>>>> referenced by = /usr/src/contrib/llvm/tools/lldb/source/API/SBProcess.cpp >>>>>> = SBProcess.o:(lldb::SBProcess::StartTrace(lldb::SBTraceOptions&, = lldb::SBError&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a >>> /usr/obj/usr/src/tmp/usr/bin/ld: error: undefined symbol: = lldb::SBTrace::SetTraceUID(unsigned long) >>>>>> referenced by = /usr/src/contrib/llvm/tools/lldb/source/API/SBProcess.cpp >>>>>> = SBProcess.o:(lldb::SBProcess::StartTrace(lldb::SBTraceOptions&, = lldb::SBError&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a >>> c++: error: linker command failed with exit code 1 (use -v to see = invocation) >>> --- lldb.full --- >>> *** [lldb.full] Error code 1 >>>=20 >>> make[5]: stopped in /usr/src/usr.bin/clang/lldb >>> 1 error >>>=20 >>> make[5]: stopped in /usr/src/usr.bin/clang/lldb >>> --- all_subdir_usr.bin/clang/lldb --- >>> *** [all_subdir_usr.bin/clang/lldb] Error code 2 >>=20 >> I've tried an amd64 -> TARGET_ARCH=3Dpowerpc64 cross build >> (builworld buildkernel) using WITH_LLD=3D and WITHOUT_LLDB=3D >> and the combination built. >>=20 >> So for powerpc64 I've only had buildworld buildkernel >> problems when attempting WITH_LLDB=3D style builds. (I've >> not tested installing or running yet.) >>=20 >> (This is not a test of distrib-dirs distribution >> use. That is a separate issue.) >=20 > My aarch64 buildworld buildkernel completed finally. > Using WITH_LLDB=3D had no problem for amd64 -> > TARGET_ARCH=3Daarch64 buildworld buildkernel doing > the -r321109 to -r321371 upgrade. I did not see > the problem for amd64 (self hosted). >=20 > I'll try armv7 (cortex-a7) next, the last of > the TARGET_ARCH=3D<?> that I normally build. >=20 > So far I've seen the problem only for powerpc64. > (I do not build lldb for 32-bit powerpc because > the lack of 8-byte atomics for powerpc historically > blocked the lldb build.) As for trying armv6/7 (cortex-a7): I forgot that linking lldb historically failed for targeting cortex-a7 based on the historical system binutils. The build was with WITHOUT_LLDB=3D (as is my standard procedure for cortex-a7) so not a relevant test. =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?3E5E8DE4-0135-4071-A041-F56DB53EE3F3>