This is the mail archive of the mailing list for the GCC 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] Fix cross compilation to Solaris

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

        * (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, the earliest after
the rename from  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 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 Orth, Center for Biotechnology, Bielefeld University

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