This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] AM_ICONV to native-only


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]