-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

[Mark Millard]

[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_private10formatters23NSNumberSummaryProviderERNS_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.

===
Mark Millard
markmi at dsl-only.net