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

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)