Fallout (mostly runtime library-related) from GCC version number change

[Zack Weinberg]

This lengthy patch attempts to address consequences of the change to
the way the compiler itself determines its version number, upon a
bunch of other top-level directories.  I erred in not checking the
entire source tree for constructs similar to the ones dealt with in
this patch; also in not thoroughly testing 'make install'.

The primary observed bug in the previous patch was that $(libsubdir)
isn't set correctly; things get installed into
$(prefix)/lib/gcc/$(target_alias)/const (yes, "const"; I don't know
where that's coming from) instead of the proper .../$(gcc_version).

The biggest other bug introduced by the previous patch was that I
failed to remove uses of TL_AC_GCC_VERSION() from a large number of
configure.ac/in scripts.  This was masked because no one has yet
needed to run autoconf in one of the affected directories.

I do not have high confidence in this patch, and am submitting it with
changes to generated files left in in hopes that library maintainers
will audit *both* the source changes and their consequences on
generated files.  I'm especially worried about further places where
Make variables depend on the GCC version, and have not been updated.

I am running an all-languages bootstrap of this patch, which will take
several hours.  I do not intend to check in the patch (despite the
existing tree breakage) unless I hear positive confirmation from other
people that it is doing the right thing.  *Please* read and comment.

zw

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 61392 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20050316/ecb7304b/attachment.bin>