[Bug lto/52405] New: undefined references in shared library when linking the shared library with -flto

[Bug lto/52405] New: undefined references in shared library when linking the shared library with -flto

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405

             Bug #: 52405
           Summary: undefined references in shared library when linking
                    the shared library with -flto
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: doko@gcc.gnu.org


seen with the 4.6 branch, and 4.7 20120223. The object files are built with
-flto as well.  Linking the shared library with -flto results in unresolved
symbols when linking against the share library. Not building the shared library
with -flto lets the launcher link succeed.

the object files (x86_64-linux-gnu) including the build script build.sh can be
found at
http://people.debian.org/~doko/tmp/hs.tar.xz

The undefined symbols come from inline template definitions in a header file.

gcc-4.7 -m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden
-m64 -flto -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer
-fuse-linker-plugin -Xlinker -O1 -Wl,-Bsymbolic-functions   -Xlinker -z
-Xlinker noexecstack -m64 -Xlinker -export-dynamic  -L `pwd` -o gamma
launcher/java_md.o launcher/wildcard.o launcher/java.o launcher/jli_util.o
-ljvm -lm -ldl -lpthread
/home/packages/openjdk/7/openjdk-7-7~u3-2.1/build/openjdk.build-boot/hotspot/outputdir/linux_amd64_compiler2/product/libjvm.so:
undefined reference to `void
G1ParPushHeapRSClosure::do_oop_nv<oopDesc*>(oopDesc**)'
/home/packages/openjdk/7/openjdk-7-7~u3-2.1/build/openjdk.build-boot/hotspot/outputdir/linux_amd64_compiler2/product/libjvm.so:
undefined reference to `void
FilterIntoCSClosure::do_oop_nv<oopDesc*>(oopDesc**)'
/home/packages/openjdk/7/openjdk-7-7~u3-2.1/build/openjdk.build-boot/hotspot/outputdir/linux_amd64_compiler2/product/libjvm.so:
undefined reference to `void G1ParPushHeapRSClosure::do_oop_nv<unsigned
int>(unsigned int*)'
collect2: error: ld returned 1 exit status
make[8]: *** [gamma] Error 1

[Bug lto/52405] undefined references in shared library when linking the shared library with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-02-28
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-28 10:44:20 UTC ---
Please specify how you build/link your shared library.  Which binutils version
are you using?  Are you using the linker plugin?  Does it work with
-fno-use-linker-plugin?  Does it work with -flto-partition=none?

[Bug lto/52405] undefined references in shared library when linking the shared library with -flto

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #2 from Matthias Klose <doko at gcc dot gnu.org> 2012-02-28 13:35:17 UTC ---
binutils from the 2.22 release branch is used.

yes, using the linker plugin.

options to build the shared library (see build.sh)
-m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -m64 -flto
-flto-partition=none -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer
-Xlinker -O1 -Wl,-Bsymbolic-functions   -Xlinker -z -Xlinker noexecstack
-shared -Xlinker --version-script=mapfile_reorder -Xlinker -soname=libjvm.so -o
libjvm.so

reducing these to
-m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -flto
-flto-partition=none -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer
-Wl,-Bsymbolic-functions -Xlinker -z -shared -Xlinker -soname=libjvm.so -o
libjvm.so
doesn't change things.

-fno-use-linker-plugin doesn't change things.

-flto-partition=none doesn't change things.

[Bug lto/52405] undefined references in shared library when linking the shared library with -flto

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-28 14:36:47 UTC ---
We do have known issues with linker options not being reflected correctly
in the resolution file.  As it is inlines and you use -fvisibility=hidden
I expect that the -Xlinker --version-script=mapfile_reorder is not
re-applied after final link optimization but only to the (fat) object file
result from compile.  So some functions may not be catched by the version
script globbing (or they are renamed as comdats are brought local, and thus
may no longer match any of the globs)?

Please help reducing this on your side.

[Bug lto/52405] undefined references in shared library when linking the shared library with -flto

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |link-failure
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The file http://people.debian.org/~doko/tmp/hs.tar.xz no longer exists and
there was no movement in reducing the LTO failure and many things has
changed/improvement since GCC 4.7 with respect to LTO so closing as invalid. If
you get a new testcase please attach it and/or give instructions how to build
the project without a temporary storage location.