This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] AM_ICONV to native-only
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 14 Feb 2007 12:38:07 -0800
- Subject: Re: [v3] AM_ICONV to native-only
- References: <45D2EF45.6020404@redhat.com>
Benjamin Kosnik wrote:
> However, the enclosed patch fixes the configure fail in all cases, by
> moving AM_ICONV to native only.
>
> tested x86/linux
> tested x86/linux x powerpc-eabi (without --with-newlib)
Does this mean that we may potentially see different behavior in cross
vs. native builds? I don't know enough to know, so this is a serious
question; not a rhetorical one.
We are trying to eliminate, across the toolchain, differences in
configuring for a given target system that are in any way dependent on
the host system. For example, we don't want a native configure on
powerpc-linux-gnu to result in different bits than a cross configure to
powerpc-linux-gnu, assuming that the same GLIBC headers and libraries
are available in both cases.
So, hard-coding the newlib case makes sense; you know it has this
functionality. But, for non-newlib targets, it seems like we now may
have a difference between cross and native, which would be a bug. I
believe that the agreed solution for cases that can't be determined in
cross environments was to provide a configure-time option to explicitly
say which mode is desired. The default can be set to whatever setting
is best, provided it's consistent across cross and native builds.
Again, it's entirely possible this is a total red herring in this case;
I'm just making sure we consider the issue.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713