Re: anyone know how to get rid of this error? (10.4/Gcc vs binutils port)

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