From owner-freebsd-current@freebsd.org Tue Oct 3 16:56:18 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 EB77BE425F5 for ; Tue, 3 Oct 2017 16:56:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 CF218810ED for ; Tue, 3 Oct 2017 16:56:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c672136a-a85b-11e7-a937-4f970e858fdb X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id c672136a-a85b-11e7-a937-4f970e858fdb; Tue, 03 Oct 2017 16:56:18 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v93GuALN001521; Tue, 3 Oct 2017 10:56:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1507049770.86205.16.camel@freebsd.org> Subject: Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port) From: Ian Lepore To: Julian Elischer , "ports@FreeBSD.org" , freebsd-current Date: Tue, 03 Oct 2017 10:56:10 -0600 In-Reply-To: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> References: <1889a630-f0c6-295d-4fda-8b843841b36d@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 16:56:19 -0000 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