http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> --- LTO-ing libbackend.a into every frontend binary theoretically results in better code. I did not see numbers on this. Now I understand what you complain about. LTO build optimizes out the symbol or makes it static, while non-LTO build produces weak. I think this is correct: weak symbols should be always produced by the unit that needs it unless they are keyed. This one does not seem to be. _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295 (transferNodesFromList) @0x7fd527d7ee18 Type: function definition analyzed Visibility: externally_visible prevailing_def_ironly_exp public weak comdat comdat_group:_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_ one_only next sharing asm name: 9004 References: Referring: Read from file: BasicBlock.o First run: 0 Function flags: Called by: _ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE8transferENS_14ilist_iteratorIS1_EERS4_S6_S6_/3184 (0.90 per call) (can throw external) Calls: _ZN4llvm10BasicBlock9setParentEPNS_8FunctionE/2560 (1.36 per call) (can throw external) _ZN4llvm16ValueSymbolTable13reinsertValueEPNS_5ValueE/4100 (2.24 per call) (can throw exte So I think the problem really is libLLVMAsmParser.so requring this symbol while not providing weak definition. Can you look into resolution file and -fdump-ipa-cgraph file how the symbol looks like while building the library? It may also be error on llvm side declaring the symbol but not providing inline definition within some source file of libASMParser. (I saw similar things in Firefox)
