public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "eebssk1 at godaftwithebk dot pub" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/108389] New: LTO(plugin) can not find lto-ed symbols
Date: Thu, 12 Jan 2023 19:00:55 +0000 [thread overview]
Message-ID: <bug-108389-4@http.gcc.gnu.org/bugzilla/> (raw)
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.
next reply other threads:[~2023-01-12 19:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 19:00 eebssk1 at godaftwithebk dot pub [this message]
2023-01-12 19:04 ` [Bug lto/108389] " eebssk1 at godaftwithebk dot pub
2023-02-18 18:16 ` eebssk1 at godaftwithebk dot pub
2023-02-18 18:23 ` eebssk1 at godaftwithebk dot pub
2023-02-18 19:12 ` eebssk1 at godaftwithebk dot pub
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-108389-4@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).