https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108389
Bug ID: 108389
Summary: LTO(plugin) can not find lto-ed symbols
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: eebssk1 at godaftwithebk dot pub
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I had compiled mingw32 crt with LTO on (fat objects enabled to maintain
compability).
However when I trying to compile a dll(also with lto),I got undefined reference
at final linking.
like:
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `pthread_once':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../mingw-w64-libraries/winpthreads/src/thread.c:762:
undefined reference to `fprintf'
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `_amsg_exit':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/mingw-w64-crt/../../mingw-w64-crt/crt/ucrtbase_compat.c:106:
undefined reference to `fprintf'
/home/eebssk1/mingw32/x86_64-w64-mingw32/bin/../lib/gcc/x86_64-w64-mingw32/12.2.1/../../../../x86_64-w64-mingw32/bin/ld:
/tmp/ccImpF6y.ltrans0.ltrans.o: in function `rwl_print':
/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../mingw-w64-libraries/winpthreads/src/rwlock.c:139:
undefined reference to `printf'
from verbose ld:
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)libapi-ms-win-crt-heap-l1-1-0s00025.o
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)libapi-ms-win-crt-heap-l1-1-0s00026.o
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_vfprintf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_vfprintf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_printf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_printf.o:
no new IR symbols to claim
(/home/eebssk1/g/mingw-crt-build/mingw-w64-mingw-w64/build/../out/lib/libmsvcrt.a)lib64_libucrt_extra_a-ucrt_fprintf.o:
no new IR symbols to claim
These objects really have lto-ed reference indeed.
lib64_libucrt_extra_a-ucrt_printf.o:
U __acrt_iob_func
0000000000000000 b .bss
0000000000000000 d .data
0000000000000000 d .data$__imp_printf
0000000000000000 N .debug_abbrev
0000000000000000 N .debug_aranges
0000000000000000 N .debug_frame
0000000000000000 N .debug_info
0000000000000000 N .debug_line
0000000000000000 N .debug_line_str
0000000000000000 r .gnu.lto_.decls.c11a8587d357cea5
0000000000000000 r .gnu.lto_.ext_symtab.c11a8587d357cea5
0000000000000000 r .gnu.lto_.icf.c11a8587d357cea5
0000000000000000 r .gnu.lto___imp_printf.120.c11a8587d357cea5
0000000000000000 r .gnu.lto_.inline.c11a8587d357cea5
0000000000000000 r .gnu.lto_.ipa_modref.c11a8587d357cea5
0000000000000000 r .gnu.lto_.ipa_sra.c11a8587d357cea5
0000000000000000 r .gnu.lto_.jmpfuncs.c11a8587d357cea5
0000000000000000 r .gnu.lto_.lto.c11a8587d357cea5
0000000000000000 r .gnu.lto_.opts
0000000000000000 r .gnu.lto_printf.119.c11a8587d357cea5
0000000000000000 r .gnu.lto_.profile.c11a8587d357cea5
0000000000000000 r .gnu.lto_.pureconst.c11a8587d357cea5
0000000000000000 r .gnu.lto_.refs.c11a8587d357cea5
0000000000000000 r .gnu.lto_.symbol_nodes.c11a8587d357cea5
0000000000000000 r .gnu.lto_.symtab.c11a8587d357cea5
0000000000000000 D __imp_printf
0000000000000000 p .pdata
0000000000000000 T printf
0000000000000000 r .rdata$zzz
U __stdio_common_vfprintf
0000000000000000 t .text
0000000000000000 r .xdata
If I manually extract these objects and append them at compiler commandline,
then the final linking successed.
It looks like the gcc lto plugin does not want to handle them.
The problem is persist both on linux cross compiling environment and windows
msys2 environemnt.
