This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: uClibc support patch
- From: Mark Mitchell <mark at codesourcery dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, Paul Brook <paul at codesourcery dot com>, Richard Earnshaw <rearnsha at arm dot com>, Nick Clifton <nickc at redhat dot com>
- Date: Mon, 13 Feb 2006 12:43:29 -0800
- Subject: Re: uClibc support patch
- References: <Pine.LNX.4.64.0602101816590.29089@digraph.polyomino.org.uk>
Joseph S. Myers wrote:
> This patch adds support for uClibc as an alternative library to glibc
> on *-*-linux* targets.
Benjamin has approved the V3 bits, and Richard Sandiford has approved
the MIPS bits.
The processor-independent bits are also OK, and the ARM bits are OK if
an ARM maintainer doesn't object within 24 hours. (They've been copied
on this message as a heads-up.)
It does look to me as though specifying both -muclibc and -mglibc may do
the wrong thing. For example, in a compiler configured for GLIBC,
saying "-muclibc -mglibc" looks as though it will use uClibc, based on
the CHOOSE_DYNAMIC_LINKER spec, even though I think people would expect
that to use GLIBC. I don't know of any way (purely in specs, as opposed
to override_options) to take ordering into account. I think it would be
better to issue an error if both are specified, which can be done in
specs. If you concur, would you please post a follow-up patch to do that?
Also, IIUC, -muclibc will be silently ignored on the GNU/Linux targets
that have not been updated. I don't see any way around that until those
targets are indeed updated as you suggest. I don't think it should be a
requirement for your patch, but if you are able to make the mechanical
changes you mentioned as a follow-up patch, I think that would be helpful.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713