The toplevel config-ml.in configure fragment has some code for a few
targets that allows modifying the set of multilibs built, based on
configure options, to be different from that given by $CC -print-multi-lib.
The options in question are described in GCC's install.texi (but the
lists there may not be accurate):
Some targets provide finer-grained control over which multilibs are built
(e.g., @option{--disable-softfloat}):
@table @code
@item arm-*-*
fpu, 26bit, underscore, interwork, biendian, nofmult.
@item m68*-*-*
softfloat, m68881, m68000, m68020.
@item mips*-*-*
single-float, biendian, softfloat.
@item powerpc*-*-*, rs6000*-*-*
aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian,
sysv, aix.
@end table
(The option handling for arc-*-elf* is to be removed for GCC 4.7 as part
of the ARC target removal.)
I'd like to deprecate these options - or more specifically, their
implementations in config-ml.in. I don't think this script is a sensible
place to hardcode multilib selections for a few particular targets, and I
think the preferred way of doing such configuration is by options that
actually take effect on GCC when it is configured so that -print-multi-lib
gives the desired set of multilibs. The options could in principle be
used when building target libraries other than GCC's (in particular,
newlib), but if you want to build a set of newlib multilibs different from
GCC multilibs I still don't think such target-specific config-ml.in
options are the right way to do it (though a generic system to specify
multilibs to build / add / remove might be).
Comments? What I am proposing is a release-notes-only deprecation - that
is, state in gcc-4.6/changes.html that these options are deprecated,
without any change to the code, with a view to removing them later in the
GCC 4.7 development cycle (to give time for maintainers to reimplement any
options they still want, in config.gcc or elsewhere in the gcc/ directory)
rather than immediately. If we can't deprecate all of them, deprecating
some would still be good.
--
Joseph S. Myers
jos...@codesourcery.com
