This is the mail archive of the gcc-patches@gcc.gnu.org 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]

Re: [3.0 critical] Make fixproto deal with assert.h (bootstrap fails)


Mark Mitchell <mark@codesourcery.com> writes:
>>>>>> "Zack" == Zack Weinberg <zackw@Stanford.EDU> writes:

>     Zack> As a last resort, we could put __eprintf back in libgcc.a.

> I guess we'd better.  I don't see a tidy way around this problem, and
> this solution seems easiest.

> Did we ever actually install stuff in ${prefix}/include directly,
> rather than in some subdirectory?  That was a mistake, in hindsight --
> we have no way of avoiding it when compiling new versions of GCC.

Correct me if I'm wrong, but isn't this problem being caused by headers
from an old version of gcc still hanging around and interfering with the
correct operation of a newer version of gcc?  If so, and this is just my
opinion, it seems perfectly reasonable to me to say that gcc doesn't
function properly when there are old parts of previous gcc versions
hanging around in non-versioned directories.  gcc would certainly be far
from the only program with that constraint.

I think it's reasonable to ask people to completely uninstall or rename
things outside gcc's versioned gcc-lib directory left over from older
versions of the compiler.  Trying to be compatible with left-over pieces
of older versions of the compiler seems to be a rather strong and
difficult constraint, particularly for a new .0 release.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>


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