This is the mail archive of the gcc-patches@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]

Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto


On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote:
>> >> > 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:
>> >
>> > Sure, but there was -fPIC used to compile all the *.o files that are being
>> > linked into libcc1.so, so LTO should know that.
>>
>> And it does.  If not please file a bug with a smaller testcase than libcc1
>> and libiberty.
>
> Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS)
> to the libcc1 rules iff the libcc1 module is built by the newly built
> bootstrapped compiler (but not when the compiler is not bootstrapped and
> thus it is built by the host compiler), because if we first bootstrap the
> compiler and build libcc1 by stage3, it is really post-stage1 building.

It doesn't help. The problem is the missing -fPIC when libtool calls
g+++ to create the shared object.  My patch fixes it.

-- 
H.J.


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