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

2017-07-26 Thread Mark Millard
On 2017-Jul-24, at 7:28 AM, Warner Losh  wrote:

>> On Mon, Jul 24, 2017 at 1:33 AM, Mark Millard  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  wrote:
>> 
>> > [Using WITH_LLDB= had no problem for amd64 -> TARGET_ARCH=aarch64
>> > buildworld buildkernel .]
>> . . .
>> >
>> > 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.

Just FYI: Attempting WITH_LLDB= in a amd64 -> armv6/7 cross
build of -r321493 failed as shown below despite using:

XCFLAGS+= -mcpu=cortex-a7
XCXXFLAGS+= -mcpu=cortex-a7

(Full build context shown later.)

--- lldb.full ---
/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/usr/lib/libgcc.a(clear_cache.o): In 
function `__clear_cache':
/usr/src/contrib/compiler-rt/lib/builtins/clear_cache.c:(.text+0x1c): 
relocation truncated to fit: R_ARM_CALL against symbol `sysarch@@FBSD_1.0' 
defined in .plt section in 
/usr/obj/armv7_clang/arm.armv6/usr/src/lib/clang/libllvm/libllvm.a(regexec.o)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [lldb.full] Error code 1

make[5]: stopped in /usr/src/usr.bin/clang/lldb
.ERROR_TARGET='lldb.full'
.ERROR_META_FILE='/usr/obj/armv7_clang/arm.armv6/usr/src/usr.bin/clang/lldb/lldb.full.meta'
.MAKE.LEVEL='5'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='c++ -mcpu=cortex-a7 -mcpu=cortex-a7 -target 
armv6-gnueabihf-freebsd12.0 
--sysroot=/usr/obj/armv7_clang/arm.armv6/usr/src/tmp 
-B/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/usr/bin -O -pipe 
-I/usr/src/contrib/llvm/tools/lldb/include 
-I/usr/src/contrib/llvm/tools/clang/include -DCLANG_ENABLE_ARCMT 
-DCLANG_ENABLE_STATIC_ANALYZER -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-unknown-freebsd12.0-gnueabihf\" 
-DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd12.0\" -DDEFAULT_SYSROOT=\"\" 
-ffunction-sections -fdata-sections -g -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
-Qunused-arguments -std=c++11 -fno-except
 ions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -Wl,--gc-sections -o 
lldb.full  Driver.o 
/usr/obj/armv7_clang/arm.armv6/usr/src/lib/clang/liblldb/liblldb.a 
/usr/obj/armv7_clang/arm.armv6/usr/src/lib/clang/libclang/libclang.a 
/usr/obj/armv7_clang/arm.armv6/usr/src/lib/clang/libllvm/libllvm.a  -ledit  
-lpanel  -lncursesw   -lz -lpthread;'
.CURDIR='/usr/src/usr.bin/clang/lldb'
.MAKE='make'
.OBJDIR='/usr/obj/armv7_clang/arm.armv6/usr/src/usr.bin/clang/lldb'
.TARGETS='all'
DESTDIR='/usr/obj/armv7_clang/arm.armv6/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='arm'
MACHINE_ARCH='armv6'
MAKEOBJDIRPREFIX='/usr/obj/armv7_clang/arm.armv6'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20170720'
PATH='/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/legacy/bin:/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/usr/sbin:/usr/obj/armv7_clang/arm.armv6/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/armv7_clang/arm.armv6/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk 
/root/src.configs/src.conf.armv7-clang-bootstrap.amd64-host 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk 
/root/src.configs/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /dev/null /usr/src/usr.bin/clang/lldb/Makefile 
/usr/src/lib/clang/lldb.pre.mk /usr/src/lib/clang/clang.pre.mk 
/usr/src/lib/clang/llvm.pre.mk /usr/src/lib/clang/clang.build.mk 
/usr/src/share/mk/src.opts.mk 

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

2017-07-24 Thread Warner Losh
On Mon, Jul 24, 2017 at 1:33 AM, Mark Millard  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  wrote:
>
> > [Using WITH_LLDB= had no problem for amd64 -> TARGET_ARCH=aarch64
> > buildworld buildkernel .]
> >
> > On 2017-Jul-23, at 3:44 PM, Mark Millard  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  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 
> 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  wrote:
> 
> > On 23 Jul 2017, at 11:17, Mark Millard  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 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]: 

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

2017-07-24 Thread 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  wrote:

> [Using WITH_LLDB= had no problem for amd64 -> TARGET_ARCH=aarch64
> buildworld buildkernel .]
> 
> On 2017-Jul-23, at 3:44 PM, Mark Millard  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  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  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  wrote:
 
> On 23 Jul 2017, at 11:17, Mark Millard  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 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 ---
>>> *** 

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

2017-07-23 Thread 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  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  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  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  wrote:
>>> 
 On 23 Jul 2017, at 11:17, Mark Millard  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 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
> 

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

2017-07-23 Thread Mark Millard
[WITH_LLD= WITHOUT_LLDB= did a buildworld buildkernel
just fine for TARGET_ARCH=powerpc64 .]

On 2017-Jul-23, at 2:46 PM, Mark Millard  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  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  wrote:
>> 
>>> On 23 Jul 2017, at 11:17, Mark Millard  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 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.)


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

___
freebsd-current@freebsd.org mailing list

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

2017-07-23 Thread Mark Millard
[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  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  wrote:
> 
>> On 23 Jul 2017, at 11:17, Mark Millard  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 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



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


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

2017-07-23 Thread Mark Millard
[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  wrote:

> On 23 Jul 2017, at 11:17, Mark Millard  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()'

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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

2017-07-23 Thread Dimitry Andric
On 23 Jul 2017, at 11:17, Mark Millard  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.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


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

2017-07-23 Thread Mark Millard
[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.]

On 2017-Jul-23, at 12:42 AM, Mark Millard  wrote:

> On 2017-Jul-23, at 12:34 AM, Mark Millard  wrote:
> 
>> The devel/powerpc64-binutils is failing to link lldb.full for
>> the clang/llvm 5 based context. (I historically use WITH_LLD
>> when targeting powerpc64 but do not use lldb since it did not
>> work overall.) I will simply change to WITHOUT_LLD for now.
>> 
>> I show the build context before the full error text.
>> 
>> Build Context:
>> 
>> # /usr/local/powerpc64-freebsd/bin/ld --version
>> GNU ld (GNU Binutils) 2.28
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This program is free software; you may redistribute it under the terms of
>> the GNU General Public License version 3 or (at your option) a later version.
>> This program has absolutely no warranty.
>> 
>> # svnlite info /usr/src/ | grep "Re[plv]"
>> Relative URL: ^/head
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 321371
>> Last Changed Rev: 321371
> 
> I should have noted a converted-to-V5 historical
> patch that I have involved:
> 
> # svnlite diff /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
> Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
> ===
> --- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp(revision 
> 321371)
> +++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp(working copy)
> @@ -60,7 +60,8 @@
> static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; }
> 
> PPC64::PPC64() {
> -  PltRel = GotRel = R_PPC64_GLOB_DAT;
> +  GotRel = R_PPC64_GLOB_DAT;
> +  PltRel = R_PPC64_JMP_SLOT;
>  RelativeRel = R_PPC64_RELATIVE;
>  GotEntrySize = 8;
>  GotPltEntrySize = 8;
> 
>> # svnlite info /usr/ports/ | grep "Re[plv]"
>> Relative URL: ^/head
>> Repository Root: svn://svn.freebsd.org/ports
>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
>> Revision: 444872
>> Last Changed Rev: 444872
>> 
>> # more 
>> ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
>>  
>> kldload -n filemon && \
>> script 
>> ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-$(date
>>  +%Y-%m-%d:%H:%M:%S) \
>> env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" 
>> SRC_ENV_CONF="/root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host"
>>  \
>> WITH_META_MODE=yes \
>> MAKEOBJDIRPREFIX="/usr/obj/powerpc64vtsc_clang_altbinutils" \
>> make $*
>> 
>> # more /root/src.configs/make.conf
>> CFLAGS.gcc+= -v
>> 
>> # more 
>> /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host
>> TO_TYPE=powerpc64
>> TOOLS_TO_TYPE=${TO_TYPE}
>> VERSION_CONTEXT=12.0
>> #
>> KERNCONF=GENERIC64vtsc-NODBG
>> TARGET=powerpc
>> .if ${.MAKE.LEVEL} == 0
>> TARGET_ARCH=${TO_TYPE}
>> .export TARGET_ARCH
>> .endif
>> #
>> WITH_CROSS_COMPILER=
>> WITHOUT_SYSTEM_COMPILER=
>> #
>> WITH_LIBCPLUSPLUS=
>> WITHOUT_BINUTILS_BOOTSTRAP=
>> WITH_ELFTOOLCHAIN_BOOTSTRAP=
>> WITH_CLANG_BOOTSTRAP=
>> WITH_CLANG=
>> WITH_CLANG_IS_CC=
>> WITH_CLANG_FULL=
>> WITH_CLANG_EXTRAS=
>> WITHOUT_LLD_BOOTSTRAP=
>> WITH_LLD=
>> WITHOUT_LLD_IS_LD=
>> WITH_LLDB=
>> #
>> WITH_BOOT=
>> WITH_LIB32=
>> #
>> WITHOUT_GCC_BOOTSTRAP=
>> WITHOUT_GCC=
>> WITHOUT_GCC_IS_CC=
>> WITHOUT_GNUCXX=
>> #
>> NO_WERROR=
>> MALLOC_PRODUCTION=
>> #
>> # Avoid converts between pointers to integer types with different sign 
>> [-Werror,-Wpointer-sign]
>> # and such from blocking the build.
>> WERROR=
>> #
>> WITH_REPRODUCIBLE_BUILD=
>> WITH_DEBUG_FILES=
>> #
>> #
>> # For TO (so-called "cross") stages . . .
>> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
>> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
>> #
>> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
>> .if ${.MAKE.LEVEL} == 0
>> #
>> # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX
>> #   binding automatically.
>> #
>> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
>> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
>> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
>> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
>> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
>> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
>> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
>> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
>> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
>> .export XAS
>> .export XAR
>> .export XNM
>> .export XOBJCOPY
>> .export XOBJDUMP
>> .export XRANLIB
>> .export XSIZE
>> .export XSTRINGS
>> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
>> .export XLD
>> .endif
>> 
>> 
>> The error text:
>> 
>> --- all_subdir_lib ---
>> --- test_01 ---
>> (cd 

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

2017-07-23 Thread Mark Millard
On 2017-Jul-23, at 12:34 AM, Mark Millard  wrote:

> The devel/powerpc64-binutils is failing to link lldb.full for
> the clang/llvm 5 based context. (I historically use WITH_LLD
> when targeting powerpc64 but do not use lldb since it did not
> work overall.) I will simply change to WITHOUT_LLD for now.
> 
> I show the build context before the full error text.
> 
> Build Context:
> 
> # /usr/local/powerpc64-freebsd/bin/ld --version
> GNU ld (GNU Binutils) 2.28
> Copyright (C) 2017 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> 
> # svnlite info /usr/src/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 321371
> Last Changed Rev: 321371

I should have noted a converted-to-V5 historical
patch that I have involved:

# svnlite diff /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
===
--- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp  (revision 321371)
+++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp  (working copy)
@@ -60,7 +60,8 @@
static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; }

PPC64::PPC64() {
-  PltRel = GotRel = R_PPC64_GLOB_DAT;
+  GotRel = R_PPC64_GLOB_DAT;
+  PltRel = R_PPC64_JMP_SLOT;
  RelativeRel = R_PPC64_RELATIVE;
  GotEntrySize = 8;
  GotPltEntrySize = 8;

> # svnlite info /usr/ports/ | grep "Re[plv]"
> Relative URL: ^/head
> Repository Root: svn://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 444872
> Last Changed Rev: 444872
> 
> # more 
> ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh
>  
> kldload -n filemon && \
> script 
> ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-$(date
>  +%Y-%m-%d:%H:%M:%S) \
> env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" 
> SRC_ENV_CONF="/root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host"
>  \
> WITH_META_MODE=yes \
> MAKEOBJDIRPREFIX="/usr/obj/powerpc64vtsc_clang_altbinutils" \
> make $*
> 
> # more /root/src.configs/make.conf
> CFLAGS.gcc+= -v
> 
> # more 
> /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-host
> TO_TYPE=powerpc64
> TOOLS_TO_TYPE=${TO_TYPE}
> VERSION_CONTEXT=12.0
> #
> KERNCONF=GENERIC64vtsc-NODBG
> TARGET=powerpc
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITH_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
> #
> WITH_LIBCPLUSPLUS=
> WITHOUT_BINUTILS_BOOTSTRAP=
> WITH_ELFTOOLCHAIN_BOOTSTRAP=
> WITH_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITHOUT_LLD_BOOTSTRAP=
> WITH_LLD=
> WITHOUT_LLD_IS_LD=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITH_LIB32=
> #
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> MALLOC_PRODUCTION=
> #
> # Avoid converts between pointers to integer types with different sign 
> [-Werror,-Wpointer-sign]
> # and such from blocking the build.
> WERROR=
> #
> WITH_REPRODUCIBLE_BUILD=
> WITH_DEBUG_FILES=
> #
> #
> # For TO (so-called "cross") stages . . .
> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
> #
> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
> .if ${.MAKE.LEVEL} == 0
> #
> # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX
> #   binding automatically.
> #
> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
> .export XAS
> .export XAR
> .export XNM
> .export XOBJCOPY
> .export XOBJDUMP
> .export XRANLIB
> .export XSIZE
> .export XSTRINGS
> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
> .export XLD
> .endif
> 
> 
> The error text:
> 
> --- all_subdir_lib ---
> --- test_01 ---
> (cd /usr/src/lib/libxo/tests &&  DEPENDFILE=.depend.test_01  NO_SUBDIR=1 make 
> -f /usr/src/lib/libxo/tests/Makefile _RECURSING_PROGS=t  PROG=test_01 )
> Building 
> /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/libxo/tests/test_01.o
> --- all_subdir_usr.bin ---
> --- all_subdir_usr.bin/clang/lldb ---
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> ---