On Mon, Nov 10, 2014 at 12:16 PM, Markus Trippelsdorf <mar...@trippelsdorf.de> wrote: > 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.). >
I can handle binutils. But it takes a LONG time for GCC build changes to be reviewed. I try to avoid it as much as I can :-). -- H.J.
