[Bug ld/13557] Undef. ref. err. when linking with slim LTO obj. in static lib. (mingw32 target)

[lrn1986 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13557

LRN <lrn1986 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lrn1986 at gmail dot com

--- Comment #3 from LRN <lrn1986 at gmail dot com> ---
Created attachment 7564
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7564&action=edit
Verbose gcc and ld output

This is still unfixed as of gcc-4.9.0 and binutils-2.24.51.20140427.

I do this (the source files are the same, from attachment 6731): 

> gcc --verbose -c -flto -g -O2 foo.c -o foo.o
> gcc-ar -rcsv libfoo.a foo.o
> gcc --verbose -c -flto -g -O2 main.c -o main.o
> gcc --verbose -Wl,--verbose=2,-Map,_map -flto -g -O2 main.o -o main ./libfoo.a

And it can't resolve foo.

I did check, gcc-ar runs ar with the right -plugin=... argument. Substituting
"gcc-ar" for "ar" (or for "ar -plugin=...") does not help.

nm ./libfoo.a correctly identifies its contents as:
> foo.o:
> 00000000 T _foo
This is if i have lto_plugin in /mingw/lib/bfd-plugins; if i don't, nm says
this:
> foo.o:
> 00000000 b .bss
> 00000000 d .data
> 00000000 r .gnu.lto_.decls.a5a741ee
> 00000000 r .gnu.lto_.inline.a5a741ee
> 00000000 r .gnu.lto_.jmpfuncs.a5a741ee
> 00000000 r .gnu.lto_.opts
> 00000000 r .gnu.lto_.profile.a5a741ee
> 00000000 r .gnu.lto_.pureconst.a5a741ee
> 00000000 r .gnu.lto_.refs.a5a741ee
> 00000000 r .gnu.lto_.symbol_nodes.a5a741ee
> 00000000 r .gnu.lto_.symtab.a5a741ee
> 00000000 r .gnu.lto_foo.a5a741ee
> 00000000 r .rdata$zzz
> 00000000 t .text
> 00000001 C ___gnu_lto_slim
> 00000001 C ___gnu_lto_v1
(gcc-nm, obviously, works regardless of whether a copy of lto plugin is in
/mingw/lib/bfd-plugins, that's the point of having a wrapper).

The output of the commands listed above is attached.

Note where it says:
> attempt to open ./libfoo.a succeeded
it doesn't say:
> (./libfoo.a)foo.o
after that. My guess is that ld just does not understand the object file format
somehow. When i run exactly the same testcase on my Debian machine (with host
gcc), i do get this:
> attempt to open ./libfoo.a succeeded
> (./libfoo.a)foo.o
and everything works.

Same with the map file (not attached, i'll provide it if requrested):
i686-mingw-w64-ld mentions libfoo once:
> LOAD ./libfoo.a
Whereas on Debian libfoo is mentioned at the beginning, where archive members
included to satisfy reference by file are listed:
> ./libfoo.a(foo.o)             main.o (symbol from plugin) (foo)
(and, of course, there's a "LOAD ./libfoo.a" later on as well).

I have debug symbols for binutils and gcc. If you tell me where to look, i may
be able to trace how ld opens archives and reads object files from them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.