On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: >> On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu <hongjiu...@intel.com> wrote: >> > Hi, >> > >> > r216964 disables bootstrap for libcc1 which exposed 2 things: >> > >> > 1. libcc1 isn't compiled with LTO even when GCC is configured with >> > "--with-build-config=bootstrap-lto". It may be intentional since >> > libcc1 is disabled for bootstrap. >> > 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is >> > compiled with LTO which remembers PIC option. >> >> Why is this any special to LTO? If it is then it looks like a LTO >> (driver) issue to me? Why are we linking the pic libibterty into >> a non-pic libcc1? > > I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, > libcc1 is built normally using libtool using -fPIC only, and linked into > libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the > pic/libiberty.a, because we need PIC code in the shared libraries. > So, I don't understand the change at all. > > Jakub
This is the command line to build libcc1.la: /bin/sh ./libtool --tag=CXX --mode=link /export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/xg++ -B/export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/ -nostdinc++ `if test -f /export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then /bin/sh /export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` -L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/bin/ -B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/lib/ -isystem /export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/include -isystem /export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/sys-include -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols /export/project/git/gcc-regression/gcc/libcc1/libcc1.sym -Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath /export/project/git/gcc-regression-bootstrap/master/216981/usr/lib/../lib64 findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/pic/libiberty.a There are no -fPIC nor any other options, like -O2. Since *.lo aren't compiled with LTO and libiberty/pic/libiberty.a is compiled with LTO, linker uses libtool command line to compile libiberty/pic/libiberty.a LTO IR into regular object. Since libtool command line doesn't have -fPIC, it fails to create shared object. Since it doesn't have -O2, it isn't optimized and misses other options. Both ld and gold pull the compiler options from the first .o file with LTO IR. We can argue if linker should pull compiler option from the first LTO IR in .o and .a. But it doesn't happen today and may not be desirable at all. -- H.J.
