[Bug other/71212] Compilation of gcc (libstdc++) for foreign target platform problem.

["abominable-snowman at yandex dot ru" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212

--- Comment #4 from Petr Ovtchenkov <abominable-snowman at yandex dot ru> ---
(In reply to Petr Ovtchenkov from comment #3)
>
> ...

Is following still actual?

  # 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.

  # If Canadian cross, then don't pick up tools from the build directory.
  # Used only in GLIBCXX_EXPORT_INCLUDES.
  if test -n "$with_cross_host" &&
     test x"$build_alias" != x"$with_cross_host" &&
     test x"$build" != x"$target";
  then
    CANADIAN=yes
  else
    CANADIAN=no
  fi


Related commits are:

43390bfe2 libstdc++-v3/configure.in (pme        2002-06-18 19:07:12 +0000 265)
...
68224f8df libstdc++-v3/configure.in (pme        2003-08-05 02:00:18 +0000 281)
5495d2507 libstdc++-v3/configure.ac (amodra     2003-08-28 00:24:52 +0000 282)
...
b9e8095bd libstdc++-v3/configure.in (bkoz       2000-04-21 20:33:34 +0000 285)