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

Julian Elischer julian at
Tue Oct 3 17:07:36 UTC 2017

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

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 

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)

More information about the freebsd-ports mailing list