OK, I think I've spotted the problem -- it doesn't like that .a files
reference variables in .o files.
fugl:~/dev/lto> cat a.cpp
int var;
fugl:~/dev/lto> cat b.cpp
#include<stdio.h>
extern int var;
int main(void)
{
printf("hello: %d\n", var);
}
fugl:~/dev/lto> g++-4.5 -flto -o a.o -c a.cpp
fugl:~/dev/lto> g++-4.5 -flto -o b.o -c b.cpp
fugl:~/dev/lto> ar rc libwhatever.a b.o
fugl:~/dev/lto> ranlib libwhatever.a
fugl:~/dev/lto> g++-4.5 -flto -fwhole-program -Wl,--gc-sections -o prog -Wl,--start-group a.o libwhatever.a -Wl,--end-group
libwhatever.a(b.o): In function `main':
b.cpp:(.text+0xa): undefined reference to `var'
collect2: ld returned 1 exit status
If I put a.o into an .a file, it works. The order of a.o and libwhatever.a
doess not matter. Removing -fwhole-program fixes it.
This is a bug, right?
On Sun, Aug 08, 2010 at 12:59:51PM +0200, Steinar H. Gunderson wrote:
On Sun, Aug 08, 2010 at 12:46:54PM +0200, Steinar H. Gunderson wrote:
OK, I think I've spotted the problem -- it doesn't like that .a files
reference variables in .o files.
Actually, .a files are not recompiled for LTO at all. If I stick everything
in .a files and link, linking is very fast; if I give the same .o files on
the command line, the machine chugs for a long time and then a smaller
result comes out.
I have not tried -flto for myself yet, but what is maybe happening here
is that if lto skips archives, when you try to link a.o and
libwhatever.a through lto with -fwhole-program, lto takes only a.o and
then yes, var is optimized away, because there is no link-chain from
main to it (remember we passed -fwhole-program to it).
And then ld sees main, but does not see var.
What is ranted here is completely untested, but maybe somehow related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376