Re: r131625 - in /trunk/libstdc++-v3: ChangeLog Mak...

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 18 Jan 2008, bkoz@gcc.gnu.org wrote:

> Author: bkoz
> Date: Fri Jan 18 08:16:51 2008
> New Revision: 131625
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131625
> Log:
> 2008-01-18  Benjamin Kosnik  <bkoz@redhat.com>
> 
> 	* docs/*: To...
> 	* doc/*: ...here.
[...]

> 	* aclocal.m4: Regenerate.
> 	* config.h.in: Regenerate.
> 	* configure: Regenerate.
> 	* Makefile.in: Regenerate.
[...]

This patch has changed the autoconf and automake versions used in 
libstdc++-v3 to 2.61 and 1.10.  Please regenerate all the files with the 
documented versions of 2.59 and 1.9.6; a major upgrade is not appropriate 
for Stage 3, but instead must be coordinated among all subdirectories in 
both the gcc and src repositories (with a lot of testing of different 
configurations), at some time during Stage 1 or 2.  libstdc++ maintainers 
have the usual latitude in deciding what changes to libstdc++ are safe in 
Stage 3, but need to be much more conservative about non-bug-fix changes 
than maintainers of (say) minor target ports - libstdc++ is a major 
release-critical component - and this sort of change to tool versions 
still needs to be planned and coordinated globally.

Specificially, I have verified that this commit has broken building 
libstdc++ in a --with-build-sysroot configuration; libtool appears no 
longer to be passing the required --sysroot options down to the compiler 
when linking.  (When using --with-build-sysroot you need to pass 
LDFLAGS_FOR_TARGET and CPPFLAGS_FOR_TARGET settings to make, but that's a 
pre-existing incompleteness in --with-build-sysroot which only 
automatically sets CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET; with this 
commit, the commands that successfully built libstdc++ in such a 
configuration no longer do so.)  I have not ascertained that the version 
change rather than something else in this commit is what caused the 
breakage, but it seems likely.

The directory name change will require an update to 
maintainer-scripts/update_web_docs_libstdcxx_svn - see 
<http://gcc.gnu.org/ml/gccadmin/2008-q1/msg00032.html> for the failure 
caused.

HJ has also reported a parallel build bug 
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851>; this hasn't been 
confirmed, but the automake upgrade is a likely cause if such a bug has 
indeed appeared.

-- 
Joseph S. Myers
joseph@codesourcery.com