From owner-freebsd-ppc@freebsd.org Mon Jul 24 07:33:19 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CBF4C08265 for ; Mon, 24 Jul 2017 07:33:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-38.reflexion.net [208.70.210.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A6D884000 for ; Mon, 24 Jul 2017 07:33:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14023 invoked from network); 24 Jul 2017 07:33:17 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Jul 2017 07:33:17 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 24 Jul 2017 03:33:17 -0400 (EDT) Received: (qmail 25767 invoked from network); 24 Jul 2017 07:33:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Jul 2017 07:33:17 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id C2923EC805D; Mon, 24 Jul 2017 00:33:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: 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 From: Mark Millard In-Reply-To: Date: Mon, 24 Jul 2017 00:33:16 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <3E5E8DE4-0135-4071-A041-F56DB53EE3F3@dsl-only.net> References: <9EF818CD-73FC-4283-8CC2-4BA21342CFB1@dsl-only.net> <98DFB763-0CA4-45B3-98E3-050462A9EC15@dsl-only.net> <9D2961AE-D423-4ED4-B16D-308BA19AC7A0@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 07:33:19 -0000 [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=3D had no problem for amd64 -> TARGET_ARCH=3Daarch64 > buildworld buildkernel .] >=20 > On 2017-Jul-23, at 3:44 PM, Mark Millard wrote: >=20 >> [WITH_LLD=3D WITHOUT_LLDB=3D did a buildworld buildkernel >> just fine for TARGET_ARCH=3Dpowerpc64 .] >>=20 >> On 2017-Jul-23, at 2:46 PM, Mark Millard wrote: >>=20 >>> [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.] >>>=20 >>> On 2017-Jul-23, at 1:04 PM, Mark Millard = wrote: >>>=20 >>>> [The lldb problem is a: >>>>=20 >>>> lldb_private::AppleObjCRuntime::GetFoundationVersion() >>>>=20 >>>> 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.] >>>>=20 >>>> On 2017-Jul-23, at 5:00 AM, Dimitry Andric wrote: >>>>=20 >>>>> On 23 Jul 2017, at 11:17, Mark Millard = wrote: >>>>>>=20 >>>>>> [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.] >>>>> ... >>>>>>=20 >>>>>> Here is the lldb.full failure text: >>>>>>=20 >>>>>> --- all_subdir_usr.bin --- >>>>>> --- all_subdir_usr.bin/clang/lldb --- >>>>>> c++: error: linker command failed with exit code 1 (use -v to see = invocation) >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> --- lldb.full --- >>>> = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib/cla= ng/liblldb/liblldb.a(Cocoa.o): In function = `lldb_private::formatters::NSNumberSummaryProvider(lldb_private::ValueObje= ct&, lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)': >>>> = /usr/src/contrib/llvm/tools/lldb/source/Plugins/Language/ObjC/Cocoa.cpp:(.= text._ZN12lldb_private10formatters23NSNumberSummaryProviderERNS_11ValueObj= ectERNS_6StreamERKNS_18TypeSummaryOptionsE+0x398): undefined reference = to `lldb_private::AppleObjCRuntime::GetFoundationVersion()' >>>=20 >>> The first error in Shawn Webb's logfile looks like what I report: >>>=20 >>> error: undefined symbol: = lldb_private::AppleObjCRuntime::GetFoundationVersion() >>>=20 >>> via Cocoa.o in liblldb.a . See below: >>>=20 >>> =3D=3D=3D> 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::V= alueObject&, lldb_private::Stream&, lldb_private::TypeSummaryOptions = const&)) in archive /usr/obj/usr/src/lib/clang/liblldb/liblldb.a >>>=20 >>> After that his log showed: >>>=20 >>> /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 >>>=20 >>> make[5]: stopped in /usr/src/usr.bin/clang/lldb >>> 1 error >>>=20 >>> 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 >>=20 >> I've tried an amd64 -> TARGET_ARCH=3Dpowerpc64 cross build >> (builworld buildkernel) using WITH_LLD=3D and WITHOUT_LLDB=3D >> and the combination built. >>=20 >> So for powerpc64 I've only had buildworld buildkernel >> problems when attempting WITH_LLDB=3D style builds. (I've >> not tested installing or running yet.) >>=20 >> (This is not a test of distrib-dirs distribution >> use. That is a separate issue.) >=20 > My aarch64 buildworld buildkernel completed finally. > Using WITH_LLDB=3D had no problem for amd64 -> > TARGET_ARCH=3Daarch64 buildworld buildkernel doing > the -r321109 to -r321371 upgrade. I did not see > the problem for amd64 (self hosted). >=20 > I'll try armv7 (cortex-a7) next, the last of > the TARGET_ARCH=3D that I normally build. >=20 > 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=3D (as is my standard procedure for cortex-a7) so not a relevant test. =3D=3D=3D Mark Millard markmi at dsl-only.net