This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/84579] New: __gnu_lto_v1 should be removed when linking with -fno-lto


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]