Re: [PATCH] Fix PR38862 (bootstrap failure graphite vs. static linking)

[Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>]

Hello,

* Joseph S. Myers wrote on Sun, Jan 18, 2009 at 02:42:54AM CET:
> 
> No, you simply need to link with the libstdc++ that was used when building 
> PPL (which would have needed a C++ compiler to build).
> 
> If that is static (as here) then there are no problems using the new 
> compiler.  If it has the same SONAME as the newly built libstdc++ then the 
> binaries should work when run with the new libstdc++.

This assumes that the newly built libstdc++ is newer than the one PPL
was linked against.  This assumption may not be true when, say, you're
trying to create a 4.4.3 release but PPL was created with a libstdc++
that came from 4.5.1 but nonetheless happens to have the same SONAME.

IOW, your assumption only holds true for the most recent development
tree, but most people's assumption is that one can build compiler
versions which are a bit older, also on then-current systems.

>  And if it has a 
> different SONAME, it's necessary to use the old library not the new one, 
> unless you include PPL in the bootstrap process, as the PPL binaries won't 
> be compatible with the new one.  (If GCC becomes written in C++ and PPL 
> becomes required, it will be necessary to be able to incorporate PPL 
> smoothly in the bootstrap process to handle SONAME transitions.)
> 
> Similarly, the issue applies when building cross compilers, when exactly 
> one libstdc++ is relevant: that used to build PPL.


> > Presumably enabling a four stage bootstrap would just mean hacking up
> > Makefile.def and Makefile.tpl some more.  Then we could just link
> > explicitly against the libstdc++ in the previous stage.  In general I
> 
> Additional work (depending on the host) would be needed to ensure the new 
> libstdc++ is found when the new compiler binaries are executed in 
> subsequent bootstrap stages, if they are dynamically linked with it.  
> (libtool relinks at install time on some platforms to deal with such 
> problems.)

Yep.

> > think it will work to simply add -lstdc++ and perhaps -lm; I don't
> > think it would be necessary to actually do the link with the g++
> > driver.
> 
> With the option to use -Wl,-Bstatic,-lstdc++,-Bdynamic to create a binary 
> not depending on a particular shared libstdc++.  (As not all linkers 
> handle those options, perhaps a --with-host-libstdc++ or similar configure 
> option would be best for the general case.)

Please note that libtool currently doesn't cope too well with
-Wl,-Bstatic,-lstdc++,-Bdynamic (it reorders it before other -l
options).  If that is critically needed, then please speak up,
we have some patches that can help fix this.

Cheers,
Ralf