From owner-freebsd-current@freebsd.org Tue Oct 3 17:07:36 2017 Return-Path: Delivered-To: freebsd-current@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 3DE69E42B2D; Tue, 3 Oct 2017 17:07:36 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F7AD81956; Tue, 3 Oct 2017 17:07:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (106-68-131-198.dyn.iinet.net.au [106.68.131.198]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v93H7T5K040003 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Oct 2017 10:07:32 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port) To: Ian Lepore , "ports@FreeBSD.org" , freebsd-current References: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> <1507049770.86205.16.camel@freebsd.org> From: Julian Elischer Message-ID: Date: Wed, 4 Oct 2017 01:07:23 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1507049770.86205.16.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2017 17:07:36 -0000 On 4/10/17 12:56 am, Ian Lepore wrote: > On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote: >> Our 10.4 system is using gcc (for now). >> >> when we compile the devel/binutils port, we get a failure with a >> bunch >> of these errors: >> >> >> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section >> `.rodata' of aarch64.o: defined in discarded section >> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE[_ZTSN12_GLOBAL__ >> N_110Stub_tableILi64ELb1EEE]' >> of aarch64.o >> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section >> `.rodata' of aarch64.o: defined in discarded section >> `.rodata._ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE[_ZTSN12_GLOBAL__ >> N_110Stub_tableILi64ELb0EEE]' >> of aarch64.o >> >> >> I managed to defeat these one before but I forget how. >> >> possibly the answer is to use clang/clang++ for this item but I >> tried >> defining CC and CXX  to clang/clang++ in the Makefile but that >> didn't >> seem to help >> >> there's probably a USE_CLANG option or something that I haven't seen. > We ran into the same thing recently at $work.  The root cause for us > involved having same-named classes in anonymous namespaces in different > compilation units.  The classes made reference to something that was > declared extern "C", bringing into play some rules about how C things > in anon namespaces really refer to the same global C object outside of > any namespace.  Then link-time optimization led to discarding the > object from one compilation unit, and that somehow resulted in > discarding the referenced extern "C" thing completely, even though it > was still referenced from the non-discarded instance of an object from > a different compilation unit.  Phew. > > The same code has no problems with clang on freebsd 11, just with gcc > on 10.3. > > So, for us the fix was a bit heavy-handed: we just renamed one of the > classes involved in the problem so that there were no longer any same- > named classes in anon namespaces in separate compilation units. >  Probably not a good option for you.  A fix involving compile options > might result in not discarding unreferenced segments at all, and with > templated code that might result in huge binaries. > > Mixing clang-compiled and gcc-compiled c++ may give you grief with > exceptions and other things (it would on ARM on 10.x, but maybe not on > x86 arches). > > -- Ian > > thanks the issue comes up in the binutils port which is a dependency of gdb. I don't think we actually need to install the binutils port on our appliance, (and we only install gdb to generate backtraces on debug reports) I just added CC=clang and CXX=clang++ in the makefile that called it and the problem seemed to go away. All i wanted to do is get gdb compiled and I end up with gcc6, llvm and binutils (plus a whole lot more) as a bonus (plus an extra 30 minutes of compile time)