This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Deprecating config-ml.in multilib selection options
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Cc: newlib at sourceware dot org, nickc at redhat dot com, richard dot earnshaw at arm dot com, paul at codesourcery dot com, ramana dot radhakrishnan at arm dot com, law at redhat dot com, schwab at linux-m68k dot org, echristo at apple dot com, rdsandiford at googlemail dot com, geoffk at geoffk dot org, dje dot gcc at gmail dot com
- Date: Mon, 21 Mar 2011 14:36:58 +0000 (UTC)
- Subject: Deprecating config-ml.in multilib selection options
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
joseph@codesourcery.com