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 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
On Mon, Jul 24, 2017 at 1:33 AM, Mark Millardwrote: > [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
[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 Millardwrote: > [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
[Using WITH_LLDB= had no problem for amd64 -> TARGET_ARCH=aarch64 buildworld buildkernel .] On 2017-Jul-23, at 3:44 PM, Mark Millardwrote: > [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
[WITH_LLD= WITHOUT_LLDB= did a buildworld buildkernel just fine for TARGET_ARCH=powerpc64 .] On 2017-Jul-23, at 2:46 PM, Mark Millardwrote: > [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
[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 Andricwrote: > >> 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
[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 Andricwrote: > 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
On 23 Jul 2017, at 11:17, Mark Millardwrote: > > [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
[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
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) > ---