Hi, With the most recent Debian gcc snapshot[1] and using the gold linker[2], I'm getting linker "undefined reference" errors when compiling with LTO. This only happens when the object file containing the undefined symbol is stored in an .a archive. If I do the same link, but using the same .o file, it succeeds (and without LTO at all, the .a file works). [1] gcc (Debian 20131121-1) 4.9.0 20131121 (experimental) [trunk revision 205215] [2] GNU gold (GNU Binutils for Debian 2.23.90.20131116) 1.11 I've attached a simple test case that illustrates this, with some source files and a shell script "barf-build.sh" that compiles them (you can defined an environment variable CXX to specify the compiler to use, otherwise it uses "g++-snapshot"), so using "sh -x barf-build.sh": + CXX=g++-snapshot + g++-snapshot -c -flto -O3 barf-main.cc + g++-snapshot -c -flto -O3 barf-lib.cc + ar ru barf-lib.a barf-lib.o + g++-snapshot -fuse-ld=gold -o barf -flto -O3 barf-main.o barf-lib.a /tmp/ccTXw8He.ltrans0.ltrans.o:ccTXw8He.ltrans0.o:function main: error: undefined reference to 'barf::oink(std::string const&, char const**)' collect2: error: ld returned 1 exit status I notice that with this snapshot, .o files no longer contain normal generated code, and only contain the LTO intermediate form in special ELF sections.... Maybe the .a-archive indexing mechanism isn't working properly with this form? Is a particular version of binutils required to link properly now, or is this a bug somewhere? Thanks, -miles
Attachment:
gcc-lto-barf.tar.gz
Description: Tar file with example code demonstrating gcc -flto link failure
--
P.S. All information contained in the above letter is false,
for reasons of military security.
