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
of these errors:

`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
of aarch64.o
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb0EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
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
defining CC and CXX  to clang/clang++ in the Makefile but that
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 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
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to