[Bug ld/14357] New: A message "Creating library file" is printed by ld when --out-implib is specified

[lrn1986 at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14357

 Bug #: 14357
   Summary: A message "Creating library file" is printed by ld
when --out-implib is specified
   Product: binutils
   Version: 2.22
Status: NEW
  Severity: minor
  Priority: P3
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: lrn1...@gmail.com
Classification: Unclassified


Created attachment 6525
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6525
Only print "Creating library file: ..." in verbose mode

This message is displayed always, whether --verbose was specified or not.
It cuts through anything the buildsystem (tested with automake "silent rules"
and SCons "quiet" mode) does to trim the tools' output. There's no way to stop
it.

Note that similar line in dlltool only gets shown in verbose mode.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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  changed:

   What|Removed |Added

 CC||lrn1986 at gmail dot com

--- Comment #3 from LRN  ---
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:
>  T _foo
This is if i have lto_plugin in /mingw/lib/bfd-plugins; if i don't, nm says
this:
> foo.o:
>  b .bss
>  d .data
>  r .gnu.lto_.decls.a5a741ee
>  r .gnu.lto_.inline.a5a741ee
>  r .gnu.lto_.jmpfuncs.a5a741ee
>  r .gnu.lto_.opts
>  r .gnu.lto_.profile.a5a741ee
>  r .gnu.lto_.pureconst.a5a741ee
>  r .gnu.lto_.refs.a5a741ee
>  r .gnu.lto_.symbol_nodes.a5a741ee
>  r .gnu.lto_.symtab.a5a741ee
>  r .gnu.lto_foo.a5a741ee
>  r .rdata$zzz
>  t .text
> 0001 C ___gnu_lto_slim
> 0001 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.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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

--- Comment #4 from LRN  ---
This bug was independently rediscovered a couple of days ago by two other
people - http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/9699 , and
then by me as well.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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

--- Comment #5 from LRN  ---
So far my guess is that the difference is in coff_link_check_ar_symbols():

When a "normal" static library (i've made a version of libfoo.a without -flto)
is being loaded, coff_link_check_ar_symbols() lists all its symbols, finds all
global or common symbols, gets their names, and resolves them, if undefined.
"Normal" libfoo has a global symbol esym == "_foo" (with name "_foo"), which
passes all checks, and eventually is fed to add_archive_element().

LTO libfoo.a does not have that. It has a number of local 'section' symbols
(".text", ".bss" and such), a number of local symbols with esym[0] == 0 and two
common symbols with esym[0] == 0 and names "___gnu_lto_v1" and
"___gnu_lto_slim".
None of them is the right thing, as far as coff_link_check_ar_symbols() is
concerned.

My guess is that a plugin should hook up at some point (i have not been able
the identify the place where this "some point" is in the code) and handle the
symbols, but it doesn't, for some reason.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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



--- Comment #6 from LRN  ---

Created attachment 7566

  --> https://sourceware.org/bugzilla/attachment.cgi?id=7566&action=edit

A hack to fix lto linking



Built binutils with debuginfo on Debian, compared with what runs on Windows.



elf_link_add_archive_symbols() just loops through all archive symbols and c
alls

> if (!(*info->callbacks

>   ->add_archive_element) (info, element, symdef->name, &element))

for each one of them. It only needs element to be non-NULL, and to have the

bfd_object format.



_bfd_generic_link_add_archive_symbols(), on the other hand, does the checks

detailed above AND calls

> if (! (*checkfn) (element, info, &needed))

>   goto error_return;

*checkfn is coff_link_check_archive_element(), it calls

coff_link_check_ar_symbols(), which i've examined earlier.



Here's a hack that forces coff_link_check_ar_symbols() to recognize gnu lto

symbol names. My guess is that a non-hacky version should consult the plugin

(maybe call claim_file() over element or something?).



-- 

You are receiving this mail because:

You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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



--- Comment #7 from LRN  ---

No, this does not work. For real-life cases (libcairoboilerplate) ar symbol

table consists of multiple copies of ___gnu_lto_v1 and ___gnu_lto_slim or

somesuch.

The

>  arh = archive_hash_lookup (&arsym_hash, h->root.string, FALSE, FAL
SE);

lookup never considers them to be candidates for resolving undefined

references, thus 

> if (! (*checkfn) (element, info, &needed))

is never called.



Need to look further.



-- 

You are receiving this mail because:

You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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  changed:

   What|Removed |Added

   Attachment #7566|0   |1
is obsolete||

--- Comment #8 from LRN  ---
Created attachment 7567
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7567&action=edit
A hack to fix lto linking

v2:
* fixed a stupid buffer size bug (should have read the code before re-using
macros...)
* fixed an error where symbol might get mischopped if it had too many '.' in it
(now uses strrchr to find the last dot).

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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

--- Comment #9 from LRN  ---
Also, to build a working static library one must use the -s option to `ar', or
(preferably) run `ranlib' on the static library (ranlib is preferable, as `ar'
from 2.24 may not do the right thing when called with -s, even if you call it
via `gcc-ar'; git versions of binutils don't have this problem).
Not doing so results in a static archive that, when slurped, looks like it only
has multiple functions, all named either __gnu_lto_slim or __gnu_lto_v1.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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

--- Comment #12 from LRN  ---
The patch applies, binutils builds, the small testcase (attachment 6731) links
successfully. Whether it works as well for real-world cases remains to be seen
(i may be able to test it in a few days).

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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

--- Comment #13 from LRN  ---
Probably unrelated: initially lto-wrapper (ran by gcc when linking main.exe)
bailed with error "lto-wrapper: CreateProcess: No such file or directory".
This is because lto-wrapper tries to spawn a "gcc" process (likely taken from
$COLLECT_GCC), and it only searches in PATH (and maybe the directory where
lto-wrapper is located, but gcc.exe isn't there).

I fixed this by adding the bin directory (where gcc.exe is) to the PATH. This
directory is *usually* in PATH (for obvious reasons) but i don't remember this
being a strict requirement, and everything works just fine unless LTO is
involved.

This hasn't been mentioned so far, so here it is, for completeness' sake.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[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

--- Comment #14 from LRN  ---
Built around 150 packages with this patch, also built GTK with -flto.
Everything builds and works, convenience libraries are confirmed to be
slim-lto-only, there's a difference in size of the binaries. I'd say everything
is in working order. If there are corner cases left, i'm not hitting them.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils