Date: Sun, 23 Jul 2017 20:51:34 -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: <D5A9EC60-C832-498D-B29E-C96EDB990684@dsl-only.net> In-Reply-To: <BC420388-C2A9-4B6D-AB44-309FF900D935@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[Using WITH_LLDB=3D had no problem for amd64 -> TARGET_ARCH=3Daarch64 buildworld buildkernel .] On 2017-Jul-23, at 3:44 PM, Mark Millard <markmi@dsl-only.net> wrote: > [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.) 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). I'll try armv7 (cortex-a7) next, the last of the TARGET_ARCH=3D<?> that I normally build. 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.) =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?D5A9EC60-C832-498D-B29E-C96EDB990684>