[Bug ipa/64390] New: "-shared" does not resolve symbols from lto generated archives

[Bug ipa/64390] New: "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

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

            Bug ID: 64390
           Summary: "-shared" does not resolve symbols from lto generated
                    archives
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: htl10 at users dot sourceforge.net

Upgrading to 4.9.2 from 4.8.x, building R (http://www.r-project.org) with fto
fails. ("./configure --enable-lto AR=gcc-ar").

Specifically, it builds a few static archives of external libraries then tries
build a shared libraries out of it. A simplified procedure is like this:

gcc -flto -c -o routine1.o routine1.c
...
gcc -flto -c -o used_by_routine1.o used_by_routine1.c
...
gcc-ar cr libextra.a used_by_routine1.o ...
...
gcc -shared -o liboutput.so routine1.o ... libextra.a ...

the output shared library is not able to resolve any symbols with libextra.a's
content.

I found two workarounds:

- putting all the dependent *.o on the command line instead of the archive
itself.

- prepending/appending the extra libraries with the whole archive linker
directives: i.e. "-Wl,--whole-archive ../extra/tre/libtre.a
-Wl,--no-whole-archive"

I realise generating shared libraries from static archive is daft, but that's
how R is built.

[Bug ipa/64390] "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

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

--- Comment #1 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) 

ar comes from:
binutils-2.24-30.fc21.x86_64

There is a lto related build in binutils-2.24-29- .

[Bug ipa/64390] "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

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

--- Comment #3 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
I wonder if it isn't '-shared' but that a mixture of object files and archives
are being used. See also:

http://stackoverflow.com/questions/27372667/undefined-reference-cross-compiling-static-libraries-with-lto-under-gcc

I 'll give binutils 2.25 a try soon - I have got something building atm; it
looks like I need to move my system's ar & ld aside to make sure the new ones
are used, which is not trivial, and can't happen while I have something
building anyway...

[Bug ipa/64390] "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

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

Hin-Tak Leung <htl10 at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #4 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
(In reply to H.J. Lu from comment #2)
> Can you try binutils 2.25?

Trying binutils 2.25 was a great help. ranlib of 2.25 actually emit a warning
about being ran on lto archives (which ranlib of 2.24 does not - I checked
again). So the part of R I had problem building and had to work around, was
running AR and RANLIB separately; other parts were doing AR in one step, so
setting AR was sufficient except where it failed, only once. Setting
RANLIB=gcc-ranlib in addition to AR=gcc-ar works.

I would have been nice if ranlib emit a warning (so it was added in 2.25)
instead of silently going ahead; incidently ar on redhat segaulted in a
slightly out of date patch with your name on it:

" Import H.J.'s patch to add support for kernel ld -r modules."

(see https://bugzilla.redhat.com/show_bug.cgi?id=1149660#c16)

and the fix to the segfault is identical to what you already did two years ago:

commit d7f8c5c183adcaa3c313150486e15ea703a65576
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Jun 4 06:44:34 2012 -0700

    Set tdata.plugin_data first

(https://bugzilla.redhat.com/show_bug.cgi?id=1149660#c17)

So it would be nice if you could check and make sure that redhat is shipping
the latest of the 'ld -r' diff, and/or have a look at the 32-bit segault also?
( https://bugzilla.redhat.com/show_bug.cgi?id=1174065 )