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

On Mon, Jul 24, 2017 at 1:33 AM, Mark Millard <markmi_at_dsl-only.net> wrote:

> [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_at_dsl-only.net> wrote:
>
> > [Using WITH_LLDB= had no problem for amd64 -> TARGET_ARCH=aarch64
> > buildworld buildkernel .]
> >
> > On 2017-Jul-23, at 3:44 PM, Mark Millard <markmi_at_dsl-only.net> wrote:
> >
> >> [WITH_LLD= WITHOUT_LLDB= did a buildworld buildkernel
> >> just fine for TARGET_ARCH=powerpc64 .]
> >>
> >> On 2017-Jul-23, at 2:46 PM, Mark Millard <markmi_at_dsl-only.net> wrote:
> >>
> >>> [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.]
> >>>
> >>> On 2017-Jul-23, at 1:04 PM, Mark Millard <markmi at dsl-only.net>
> wrote:
> >>>
> >>>> [The lldb problem is a:
> >>>>
> >>>> lldb_private::AppleObjCRuntime::GetFoundationVersion()
> >>>>
> >>>> 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.]
> >>>>
> >>>> On 2017-Jul-23, at 5:00 AM, Dimitry Andric <dim_at_FreeBSD.org> wrote:
> >>>>
> >>>>> On 23 Jul 2017, at 11:17, Mark Millard <markmi_at_dsl-only.net> wrote:
> >>>>>>
> >>>>>> [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.]
> >>>>> ...
> >>>>>>
> >>>>>> Here is the lldb.full failure text:
> >>>>>>
> >>>>>> --- all_subdir_usr.bin ---
> >>>>>> --- all_subdir_usr.bin/clang/lldb ---
> >>>>>> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>
> >>>> --- lldb.full ---
> >>>> /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/
> usr/src/lib/clang/liblldb/liblldb.a(Cocoa.o): In function
> `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObject&,
> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)':
> >>>> /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/
> ObjC/Cocoa.cpp:(.text._ZN12lldb_private10formatters23NSNumberS
> ummaryProviderERNS_11ValueObjectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398):
> undefined reference to `lldb_private::AppleObjCRuntime::
> GetFoundationVersion()'
> >>>
> >>> The first error in Shawn Webb's logfile looks like what I report:
> >>>
> >>> error: undefined symbol: lldb_private::AppleObjCRuntime::
> GetFoundationVersion()
> >>>
> >>> via Cocoa.o in liblldb.a . See below:
> >>>
> >>> ===> 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::ValueObject&,
> lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)) in
> archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a
> >>>
> >>> After that his log showed:
> >>>
> >>> /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
> >>>
> >>> make[5]: stopped in /usr/src/usr.bin/clang/lldb
> >>> 1 error
> >>>
> >>> 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
> >>
> >> I've tried an amd64 -> TARGET_ARCH=powerpc64 cross build
> >> (builworld buildkernel) using WITH_LLD= and WITHOUT_LLDB=
> >> and the combination built.
> >>
> >> So for powerpc64 I've only had buildworld buildkernel
> >> problems when attempting WITH_LLDB= style builds. (I've
> >> not tested installing or running yet.)
> >>
> >> (This is not a test of distrib-dirs distribution
> >> use. That is a separate issue.)
> >
> > My aarch64 buildworld buildkernel completed finally.
> > Using WITH_LLDB= had no problem for amd64 ->
> > TARGET_ARCH=aarch64 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=<?> 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.)
>
> 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= (as is my standard procedure for cortex-a7)
> so not a relevant test.


lldb doesn't support armv6 ISA, but does support armv7 ISA.

Just as a point of reference. It's one of the reasons for creating a new
MACHINE_ARCH of armv7.

Warner