This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: [3.0 critical] Make fixproto deal with assert.h (bootstrap fails)
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: [3.0 critical] Make fixproto deal with assert.h (bootstrap fails)
- From: "Zack Weinberg" <zackw at Stanford dot EDU>
- Date: Sat, 12 May 2001 12:00:28 -0700
- Cc: ghazi at caip dot rutgers dot edu, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, jsm28 at cam dot ac dot uk
- References: <200105121259.IAA22988@caip.rutgers.edu> <20010512113828P.mitchell@codesourcery.com>
On Sat, May 12, 2001 at 11:38:28AM -0700, Mark Mitchell wrote:
> >>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
>
> Kaveh> I tracked this down to a local installation problem. There
> Kaveh> is an old copy of gcc's assert.h in /usr/local/include and
> Kaveh> of course its defining assert() in terms of __eprintf.
> Kaveh> That assert.h may have been placed there by an older
> Kaveh> version of gcc (2.7.x?/2.8.x?) that got installed on that
> Kaveh> system.
>
> Ugh. Zack, what do you think about this?
One possibility is for fixincludes to search for a version of assert.h
that doesn't refer to __eprintf, and copy it into libsubdir/include.
This is tricky - we don't want to do this if there is _no_ version of
assert.h which uses __eprintf; and what do we do if there is no
version which doesn't? (Assume it's in libc, probably.) And I'm not
sure how to tell fixincludes about cpp's header search path.
As a last resort, we could put __eprintf back in libgcc.a. It's not
like it takes up a lot of space. It could probably be excluded from
libgcc_s.so. And code compiled against new headers won't refer to it.
I can't convince myself there won't be issues provoked by its mere
existence, however.
--
zw This APT has Super Cow Powers.
-- apt-get 0.5