Re: [v3] Fix cross compilation to Solaris

[Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>]

Hi Jonathan,

>>This way, config.h is identical between a native build and the cross
>>above, with the exception of HAVE_SETENV which is equally guarded with
>>GLIBCXX_IS_NATIVE in acinclude.m4 (GLIBCXX_CONFIGURE_TESTSUITE).  Maybe
>>it's time to somehow refine the GLIBCXX_IS_NATIVE check to allow cross
>>configurations that *can* perform link tests to run them?
>
> Sounds like a good idea, although I don't know how to do that.

I'm not sure either, since I couldn't easily find the origin of that
variable.  The earliest ChangeLog entry mentioning it is

2003-08-17  Phil Edwards  <pme@gcc.gnu.org>

[...]
        * configure.ac (GLIBCXX_IS_NATIVE):  Determine earlier and re-order.
        Comment out the conditionals for CANADIAN and GLIBCXX_BUILD_LIBMATH
        (currently unused).  Strip the fake-VPATH shell fragment from
        automake-generated rules, if present.

and it's already present in r70194 for configure.ac, the earliest after
the rename from configure.in.  No idea what happened to earlier history
before that rename: svn should be able to cope with that, I thought.

The !$GLIBCXX_IS_NATIVE branch in configure.ac explains

  # This lets us hard-code the functionality we know we'll have in the cross
  # target environment.  "Let" is a sugar-coated word placed on an especially
  # dull and tedious hack, actually.
  #
  # Here's why GLIBCXX_CHECK_MATH_SUPPORT, and other autoconf macros
  # that involve linking, can't be used:
  #    "cannot open sim-crt0.o"
  #    "cannot open crt0.o"
  # etc.  All this is because there currently exists no unified, consistent
  # way for top level CC information to be passed down to target directories:
  # newlib includes, newlib linking info, libgloss versus newlib crt0.o, etc.
  # When all of that is done, all of this hokey, excessive AC_DEFINE junk for
  # crosses can be removed.

which suggests this is primarily an issue for builds done in a unified
tree, with gcc, binutils, newlib etc. all thrown in at once, i.e. for
embedded targets.

ISTM that one should just be able to actually *do* a link test of an
empty main, see if it works and decide from there if link tests are
possible or not.

Me only very rarely doing crosses at all, and then mostly only building
cc1/cc1plus, am certainly not a good person to try this, though ;-)

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University