On 2014.11.10 at 12:05 -0800, H.J. Lu wrote:
> On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf
> <mar...@trippelsdorf.de> wrote:
> > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote:
> >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek <ja...@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.
> >
> > But wouldn't it be better to update to a more recent libtool version
> > instead of adding hack upon hack?
> 
> Hack is safer than the newer libtool :-(.  A new libtool needs to be
> verified on all hosts for all targets.

Well, perhaps now is the right time to do it, because there would be
enough time to fix any fallout.

> > This would also allow bootstrap-lto without the need of the gcc-ar
> > (, etc.) wrappers.
> >
> > And you are one of the very few persons who could handle such an update.
> >
> 
> What did you mean by "you"?

I mean that since Ralf Wildenhues dropped from the scene, you (H.J.) are
one of the few people who could handle a libtool update across the
different trees (gcc, binutils, etc.).

-- 
Markus

Reply via email to