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) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
anyone know how to get rid of this error? (10.4/Gcc vs binutils port)
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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
