-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]

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



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