From owner-freebsd-ppc@freebsd.org Mon Jul 24 14:29:01 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 AB209C7F477 for ; Mon, 24 Jul 2017 14:29:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7326569F57 for ; Mon, 24 Jul 2017 14:29:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id v127so35951136itd.0 for ; Mon, 24 Jul 2017 07:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xtHkX3Wfdv5LHvrZimfKbcUurqMNZevFP6gMuCyOIW0=; b=wId10Rl3YXfe6sg8vT3XkChO1YeGwzUSM+Iwm+2KVjhmZNyTWt66cP10UjBXAEU08+ tSyb09mx72C7D+N8aX/5r5W02rPq4y7vk2kxjt/+NenUMAozfGlvb+PimkpBjn3LS3Dg J7l0hbgK5I0KKULe+gU6Jz0nLhwP4TC9/d3Qxc+gc/7PA6Tnw8CnPwfSrEHS1epkXekU J7srTpvs3xmtdbU5uhGVlF8eYeq5roazgxC0t4LrwDIBra9Sa//iqhTt2F7OpTOrLe3B sXc9MnNmOdGiSOcS/DdxPG93+zJkdmqpHQRsBDqX+Mrs1Ol78Q2293WzlDrgHO+GVuJp TBbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xtHkX3Wfdv5LHvrZimfKbcUurqMNZevFP6gMuCyOIW0=; b=Ql0pQDIUSRlMOIlKoNwBRMsPB1ogdKrXvuWZHq392ChBvkyGTJKp8M1q+F0ZZhRxHz cwOi+RaRLGQOHwX6R25SbmUieu+7Ny4xFIEj1W2Jwuc50Q/s/sogfIFjkgyqc5zNwlIE PNIgn8zxpKQbDM0BE7Nb2UOKqpKMpg2GG3XUJ9cjMmS6uUd9bL9TejCS9HPtNIf/RPsw J7+r0tQtwqxPwq5GrwsU5zz+3aVoFT76Ocgu+91/ScvpYICYc1F4tiuX1EVhfV3rWBzs EenEE/wOZll23G6iFCcWfCYB5LkFT2bGs1pS2+qLoB1YLv5hPIRo+zrKZ+gFxg5HNNNZ Jq4A== X-Gm-Message-State: AIVw11083yAuBLdmS8A0refYtjc3kHv4lRL4EwoZZnusgiMJ/3nBBV4u CLyl3Ud0zkE0Cv7LfPVMHaduCa7SZIMm X-Received: by 10.36.254.6 with SMTP id w6mr6860712ith.158.1500906540573; Mon, 24 Jul 2017 07:29:00 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.58.17 with HTTP; Mon, 24 Jul 2017 07:28:59 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <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> <3E5E8DE4-0135-4071-A041-F56DB53EE3F3@dsl-only.net> From: Warner Losh Date: Mon, 24 Jul 2017 08:28:59 -0600 X-Google-Sender-Auth: WqumqjmWg8sRd0LSTAph3z7i6dw Message-ID: 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 To: Mark Millard Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current , FreeBSD PowerPC ML Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 14:29:01 -0000 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]: stopped in /usr/src/usr.bin/clang/lldb > >>> 1 error > >>> > >>> make[5]: stopped in /usr/src/usr.bin/clang/lldb > >>> --- all_subdir_usr.bin/clang/lldb --- > >>> *** [all_subdir_usr.bin/clang/lldb] Error code 2 > >> > >> I've tried an amd64 -> TARGET_ARCH=powerpc64 cross build > >> (builworld buildkernel) using WITH_LLD= and WITHOUT_LLDB= > >> and the combination built. > >> > >> So for powerpc64 I've only had buildworld buildkernel > >> problems when attempting WITH_LLDB= style builds. (I've > >> not tested installing or running yet.) > >> > >> (This is not a test of distrib-dirs distribution > >> use. That is a separate issue.) > > > > My aarch64 buildworld buildkernel completed finally. > > Using WITH_LLDB= had no problem for amd64 -> > > TARGET_ARCH=aarch64 buildworld buildkernel doing > > the -r321109 to -r321371 upgrade. I did not see > > the problem for amd64 (self hosted). > > > > I'll try armv7 (cortex-a7) next, the last of > > the TARGET_ARCH= that I normally build. > > > > So far I've seen the problem only for powerpc64. > > (I do not build lldb for 32-bit powerpc because > > the lack of 8-byte atomics for powerpc historically > > blocked the lldb build.) > > As for trying armv6/7 (cortex-a7): I forgot that linking > lldb historically failed for targeting cortex-a7 based > on the historical system binutils. The build was with > WITHOUT_LLDB= (as is my standard procedure for cortex-a7) > so not a relevant test. 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. Warner