This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/84579] New: __gnu_lto_v1 should be removed when linking with -fno-lto
- From: "romain.geissler at amadeus dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 26 Feb 2018 23:23:54 +0000
- Subject: [Bug lto/84579] New: __gnu_lto_v1 should be removed when linking with -fno-lto
- Auto-submitted: auto-generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84579
Bug ID: 84579
Summary: __gnu_lto_v1 should be removed when linking with
-fno-lto
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.geissler at amadeus dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi,
When you want to build a project where for some reason you want to use fat LTO
objects, but don't want to actually use it a link time (ie when you want to
experiment with LTO but still allow to easily disable it), you might end up
doing this:
gcc -flto -ffat-lto-objects -fPIC -o file.o -c file.c
gcc -fno-lto -fPIC -shared -o file.so file.o
with gcc 8 though, this leaves the symbol __gnu_lto_v1 which is unexpected to
remains in the final shared library:
gcc-nm -g file.so
0000000000201020 B __bss_start
w __cxa_finalize@@GLIBC_2.2.5
0000000000201020 D _edata
0000000000201028 B _end
0000000000000609 T f
000000000000060c T _fini
w __gmon_start__
0000000000201021 B __gnu_lto_v1
0000000000000508 T _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
Would it be possible to trim out __gnu_lto_v1 when we have fat inbound objects,
but lto is explicitly deleted with -fno-lto ?
Cheers,
Romain