Current libreoffice fails to build with the current GCC because of bogus error: S=/home/marxin/libreoffice && O=$S/solver/unxlngx6.pro && W=$S/workdir/unxlngx6.pro && mkdir -p $W/LinkTarget/Executable/ && g++ -flto -fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -Wl,-O1 -Wl,-S $W/CxxObject/i18npool/source/localedata/LocaleNode.o $W/CxxObject/i18npool/source/localedata/filewriter.o $W/CxxObject/i18npool/source/localedata/saxparser.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -o $W/LinkTarget/Executable/saxparser /home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::Exception' /home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::RuntimeException' /home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::RuntimeException' /home/marxin/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::Exception' The typeinfo is a COMDAT symbol that is turned into static and somehow GNU LD still mixes it up with the original symbol definition. Sadly we have no self contained testcase....
By "turned into static" do you mean that the typeinfo symbol in the real object is STB_LOCAL?
> --- Comment #1 from Alan Modra <amodra at gmail dot com> 2013-05-22 16:24:05 UTC --- > By "turned into static" do you mean that the typeinfo symbol in the real object > is STB_LOCAL? typeinfo itself is not changed, just the symbol was previously common GCC localized it to static guided by RESOLVED_DEF_IRONLY resolution. For some reason this seem to break with the message above (that seems bogus, since it speaks of reference from plugin section) Honza
I could not reproduce this with current mainline binutils. The following extract from a debug session shows one of the typeinfo symbols hitting _bfd_exf_export_symbol. We get there due to -Wl,--dynamic-list-cpp-typeinfo. Notice the plugin sym doesn't have def_regular or ref_regular set, so is not exported dynamic. The second sym showed me what Jan meant by "turned into static", and is some evidence that ld is being exercised in a way that would trigger the bug if it still existed. I suspect the bug was fixed along with PR15270, or one of my other patches in late March. Jan if you can reproduce with mainline ld, please attach at set of objects that reproduce the problem, and reopen the bug. Breakpoint 2, _bfd_elf_export_symbol (h=0x114a2c0, data=0x7fffffffd1e0) at /src/binutils-current/bfd/elflink.c:1813 (gdb) p *h $28 = {root = {root = {next = 0x0, string = 0x11555fc "_ZTIN3com3sun4star3uno9ExceptionE", hash = 474875173}, type = bfd_link_hash_defweak, non_ir_ref = 1, u = {undef = {next = 0x114a2c0, abfd = 0x1135198}, def = {next = 0x114a2c0, section = 0x1135198, value = 0}, i = {next = 0x114a2c0, link = 0x1135198, warning = 0x0}, c = {next = 0x114a2c0, p = 0x1135198, size = 0}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, size = 16, type = 1, other = 0, target_internal = 0, ref_regular = 0, def_regular = 0, ref_dynamic = 1, def_dynamic = 0, ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, dynamic = 1, mark = 0, non_got_ref = 0, dynamic_def = 1, ref_dynamic_nonweak = 0, pointer_equality_needed = 0, unique_global = 0, dynstr_index = 0, u = {weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0}, vtable = 0x0} (gdb) p h->root.u.def.section->owner->filename $29 = 0x1094ee0 "/home/alan/build/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin)" (gdb) c Continuing. Breakpoint 2, _bfd_elf_export_symbol (h=0x16657d8, data=0x7fffffffd1e0) at /src/binutils-current/bfd/elflink.c:1813 (gdb) p *h $30 = {root = {root = {next = 0x0, string = 0x168264d "_ZTIN3com3sun4star3uno9ExceptionE.lto_priv.27", hash = 1034143234}, type = bfd_link_hash_defined, non_ir_ref = 1, u = {undef = {next = 0x0, abfd = 0x1680b88}, def = {next = 0x0, section = 0x1680b88, value = 1232}, i = {next = 0x0, link = 0x1680b88, warning = 0x4d0 <Address 0x4d0 out of bounds>}, c = {next = 0x0, p = 0x1680b88, size = 1232}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 3, offset = 3, glist = 0x3, plist = 0x3}, size = 16, type = 1, other = 2, target_internal = 0, ref_regular = 1, def_regular = 1, ref_dynamic = 0, def_dynamic = 0, ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, dynamic = 1, mark = 0, non_got_ref = 1, dynamic_def = 0, ref_dynamic_nonweak = 0, pointer_equality_needed = 1, unique_global = 0, dynstr_index = 0, u = {weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0}, vtable = 0x0} (gdb) p h->root.u.def.section->owner->filename $31 = 0x110e8c0 "saxparser.ltrans1.ltrans.o" (gdb) c Continuing. [Inferior 1 (process 21141) exited normally] (gdb)
> I could not reproduce this with current mainline binutils. The following > extract from a debug session shows one of the typeinfo symbols hitting > _bfd_exf_export_symbol. We get there due to -Wl,--dynamic-list-cpp-typeinfo. Martin, do you think you can double check if the mainline binutils triggers the bug or not? The error sadly happens during libreoffice build that is bit hard to turn into resoable testcase (the module is small though). I was surprised that the bug does not trigger more often, since mainline GCC since 2013-05-15 Jan Hubicka <jh@suse.cz> PR lto/57038 PR lto/47375 * lto-partition.c (get_symbol_class): Fix weakrefs. (lto_balanced_map): Fix weakrefs. (privatize_symbol_name): Remove unnecesary label. (rename_statics): Handle weakrefs as statics. produces quite a lot of such changes (previously GCC always renamed the symbol but people complained it makes debugging harder). Honza > Notice the plugin sym doesn't have def_regular or ref_regular set, so is not > exported dynamic. The second sym showed me what Jan meant by "turned into > static", and is some evidence that ld is being exercised in a way that would > trigger the bug if it still existed. I suspect the bug was fixed along with > PR15270, or one of my other patches in late March. > > Jan if you can reproduce with mainline ld, please attach at set of objects that > reproduce the problem, and reopen the bug. > > Breakpoint 2, _bfd_elf_export_symbol (h=0x114a2c0, data=0x7fffffffd1e0) at > /src/binutils-current/bfd/elflink.c:1813 > (gdb) p *h > $28 = {root = {root = {next = 0x0, string = 0x11555fc > "_ZTIN3com3sun4star3uno9ExceptionE", hash = 474875173}, type = > bfd_link_hash_defweak, non_ir_ref = 1, u = {undef = {next = 0x114a2c0, abfd = > 0x1135198}, def = {next = 0x114a2c0, section = 0x1135198, value = 0}, i = {next > = 0x114a2c0, link = 0x1135198, warning = 0x0}, c = {next = 0x114a2c0, p = > 0x1135198, size = 0}}}, indx = -1, dynindx = -1, got = {refcount = 0, offset = > 0, glist = 0x0, plist = 0x0}, plt = {refcount = 0, offset = 0, glist = 0x0, > plist = 0x0}, size = 16, type = 1, other = 0, target_internal = 0, ref_regular > = 0, def_regular = 0, ref_dynamic = 1, def_dynamic = 0, ref_regular_nonweak = > 0, dynamic_adjusted = 0, needs_copy = 0, needs_plt = 0, non_elf = 0, hidden = > 0, forced_local = 0, dynamic = 1, mark = 0, non_got_ref = 0, dynamic_def = 1, > ref_dynamic_nonweak = 0, pointer_equality_needed = 0, unique_global = 0, > dynstr_index = 0, u = {weakdef = 0x0, elf_hash_value = 0}, verinfo = {verdef = > 0x0, vertree = 0x0}, vtable = 0x0} > (gdb) p h->root.u.def.section->owner->filename > $29 = 0x1094ee0 > "/home/alan/build/libreoffice/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o > (symbol from plugin)" > (gdb) c > Continuing. > > Breakpoint 2, _bfd_elf_export_symbol (h=0x16657d8, data=0x7fffffffd1e0) at > /src/binutils-current/bfd/elflink.c:1813 > (gdb) p *h > $30 = {root = {root = {next = 0x0, string = 0x168264d > "_ZTIN3com3sun4star3uno9ExceptionE.lto_priv.27", hash = 1034143234}, type = > bfd_link_hash_defined, non_ir_ref = 1, u = {undef = {next = 0x0, abfd = > 0x1680b88}, def = {next = 0x0, section = 0x1680b88, value = 1232}, i = {next = > 0x0, link = 0x1680b88, warning = 0x4d0 <Address 0x4d0 out of bounds>}, c = > {next = 0x0, p = 0x1680b88, size = 1232}}}, indx = -1, dynindx = -1, got = > {refcount = 0, offset = 0, glist = 0x0, plist = 0x0}, plt = {refcount = 3, > offset = 3, glist = 0x3, plist = 0x3}, size = 16, type = 1, other = 2, > target_internal = 0, ref_regular = 1, def_regular = 1, ref_dynamic = 0, > def_dynamic = 0, ref_regular_nonweak = 0, dynamic_adjusted = 0, needs_copy = 0, > needs_plt = 0, non_elf = 0, hidden = 0, forced_local = 0, dynamic = 1, mark = > 0, non_got_ref = 1, dynamic_def = 0, ref_dynamic_nonweak = 0, > pointer_equality_needed = 1, unique_global = 0, dynstr_index = 0, u = {weakdef > = 0x0, elf_hash_value = 0}, verinfo = {verdef = 0x0, vertree = 0x0}, vtable = > 0x0} > (gdb) p h->root.u.def.section->owner->filename > $31 = 0x110e8c0 "saxparser.ltrans1.ltrans.o" > (gdb) c > Continuing. > [Inferior 1 (process 21141) exited normally] > (gdb) > > -- > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug.
Hello, I've just tried to build libreoffice with GNU ld (Linux/GNU Binutils) 2.23.52.0.2.20130423, latest version I am able to install on my gentoo machine, and the problem was reached. If it helps, I will checkout mainline bintuils and try it. Martin
> --- Comment #5 from Martin Liška <marxin.liska at gmail dot com> 2013-05-24 12:36:57 UTC --- > Hello, > I've just tried to build libreoffice with GNU ld (Linux/GNU Binutils) > 2.23.52.0.2.20130423, latest version I am able to install on my gentoo machine, > and the problem was reached. > > If it helps, I will checkout mainline bintuils and try it. Yes, please checkout the mainline binutils and if the problem is there try to produce preprocessed files to reproduce the bug. Thanks, Honza
Not preprocessed files, object files please. If this is a linker bug, I want the inputs to the linker, including its invocation which you can see by adding -v to the g++ command line.
I've got a good news, mainline ld does not report the problem. The bug could be closed. Martin
> --- Comment #7 from Alan Modra <amodra at gmail dot com> 2013-05-24 14:37:29 UTC --- > Not preprocessed files, object files please. If this is a linker bug, I want > the inputs to the linker, including its invocation which you can see by adding > -v to the g++ command line. Catch with object files and LTO is that they are GCC configuration specific. But lets try to get around with those. Honza
(In reply to Martin Liška from comment #8) > I've got a good news, mainline ld does not report the problem. > > The bug could be closed. > > Martin Can you also checkout hjl/lto/master branch at http://git.kernel.org/cgit/linux/kernel/git/hjl/binutils.git Thanks.
So the bug is really present in binutils trunk (May 24 2013). ld --version: GNU ld (GNU Binutils) 2.23.52.20130524 gcc --version: gcc (GCC) 4.9.0 20130517 (experimental) Compilation error: S=/home/marxin/Programming/libreoffice-lto-test && O=$S/solver/unxlngx6.pro && W=$S/workdir/unxlngx6.pro && mkdir -p $W/LinkTarget/Executable/ && g++ -flto -fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -Wl,-O1 -Wl,-S $W/CxxObject/i18npool/source/localedata/LocaleNode.o $W/CxxObject/i18npool/source/localedata/filewriter.o $W/CxxObject/i18npool/source/localedata/saxparser.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -o $W/LinkTarget/Executable/saxparser /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::Exception' /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::RuntimeException' /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo for com::sun::star::uno::RuntimeException' /home/marxin/Programming/libreoffice-lto-test/workdir/unxlngx6.pro/CxxObject/i18npool/source/localedata/saxparser.o (symbol from plugin): undefined reference to `typeinfo name for com::sun::star::uno::Exception' collect2: error: ld returned 1 exit status All 3 object files are added as an attachment. Thanks, Martin
Created attachment 7054 [details] Libreoffice saxparser object files
Test case was introduced.
I suspect you're picking up some older ld. Note addition of -Wl,-v to show versions in the following: alan@bubble:~/build/libreoffice$ B=/home/alan/build/libreoffice && O=$B/solver/unxlngx6.pro && W=$B/workdir/unxlngx6.pro && mkdir -p $W/LinkTarget/Executable/ && g++ -flto -fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$O/lib -Wl,--hash-style=gnu -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-Bsymbolic-functions -Wl,-O1 -Wl,-S $B/libreoffice-object-files/LocaleNode.o $B/libreoffice-object-files/filewriter.o $B/libreoffice-object-files/saxparser.o -Wl,--start-group -Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -o $W/LinkTarget/Executable/saxparser -Wl,-v collect2 version 4.9.0 20130522 (experimental) /usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../x86_64-linux/bin/ld -plugin /usr/local/libexec/gcc/x86_64-linux/4.9.0/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc/x86_64-linux/4.9.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccbxEkZk.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /home/alan/build/libreoffice/workdir/unxlngx6.pro/LinkTarget/Executable/saxparser /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /usr/local/lib/gcc/x86_64-linux/4.9.0/crtbegin.o -L/home/alan/build/libreoffice/solver/unxlngx6.pro/lib -L/usr/local/lib/gcc/x86_64-linux/4.9.0 -L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../../../x86_64-linux/lib -L/usr/local/lib/gcc/x86_64-linux/4.9.0/../../.. -z origin -rpath $ORIGIN/../lib:$ORIGIN -rpath-link /home/alan/build/libreoffice/solver/unxlngx6.pro/lib -z defs -rpath-link /lib:/usr/lib -z combreloc --hash-style=gnu --dynamic-list-cpp-new --dynamic-list-cpp-typeinfo -Bsymbolic-functions -O1 -S /home/alan/build/libreoffice/libreoffice-object-files/LocaleNode.o /home/alan/build/libreoffice/libreoffice-object-files/filewriter.o /home/alan/build/libreoffice/libreoffice-object-files/saxparser.o --start-group --end-group --no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal -v -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc/x86_64-linux/4.9.0/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o GNU ld (GNU Binutils) 2.23.52.20130524 alan@bubble:~/build/libreoffice$ The other possibility is that my shared libraries are masking the problem somehow. If you are running the version of ld you think you are, please attach the following shared libs: -luno_cppu (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_cppu.so) -luno_cppuhelpergcc3 (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_cppuhelpergcc3.so) -luno_sal (/home/alan/build/libreoffice/solver/unxlngx6.pro/lib/libuno_sal.so)
I'm not sure if this was fixed or not, but a 9 year old lto related bug is surely obsolete.