Re: g77's use of assert and x-compilation

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.SUN.3.93.980722000622.3151A-100000@modi.xraylith.wisc.edu>you write:
  > Basically this is what I do:
  >   
  >   1. build a cross-compiler for ix86-*-win32 (various forms of it).
  >      - Here we get a libgcc.a that lacks __eprintf.
  >   2. build a native** compiler for ix86-*-win32 using that cross-compiler.
  >      - Here we get hit due to the lack of __eprintf.
  > 
  > (*) Here native means native compiler built for the target, not for the
  > host.
  >      
  > The libgcc.a built in step 1, which is used by the cross-compiler in
  > building executables in step 2, lacks __eprintf due to the inhibit_libc
  > being defined within libgcc2.c; hence any code that uses GCC's assert.h, 
  > as opposed to system supplied one, will get hit by this.
OK.

So what assert.h are we picking during #2 above?  If we're picking up
the one installed via #1, then maybe the solution is to avoid installing
assert.h when inhibit_libc is true.

You should be able to compile an offending module from step #2 with
-save-temps, then search for assert.h to get a pathname for the
assert.h used.

In general, we should not be using assert within the gcc2 sources.  This
has been a long standing practice, but once in a while we run into code
which does not follow this convention.  The right thing to do by convention
is to call abort for "can't happen" cases.  But I don't think we want
to try and convert the g77 front-end at this time.

jeff