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

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 ever

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

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 (li

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

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 r

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

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,

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

https://sourceware.org/bugzilla/show_bug.cgi?id=13557 LRN changed: What|Removed |Added Attachment #7566|0 |1 is obsolete|

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

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_has

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

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_

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

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

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

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:

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

https://sourceware.org/bugzilla/show_bug.cgi?id=13557 LRN changed: What|Removed |Added CC||lrn1986 at gmail dot com --- Comment #3 from

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

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: