This is the mail archive of the
mailing list for the GCC project.
Re: HPPA STMP_FIXPROTO patch
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc at gcc dot gnu dot org, sje at cup dot hp dot com
- Date: Fri, 30 Aug 2002 09:59:56 -0600
- Subject: Re: HPPA STMP_FIXPROTO patch
- Reply-to: law at redhat dot com
In message <200208292340.g7TNeCMS027636@hiauly1.hia.nrc.ca>, "John David Anglin
>> > Really the way to go is to get HP to fix the hpux header files so that ne
>> > fixincludes nor fixproto are necessary. Then it becomes a hell of a lot
>> > to use tools built under one rev of the OS with newer revs of the OS.
>> I guess I can see that, are there any platforms where this can be done
>> today? I am curious how they handle some of the generic fixincludes
>> changes like mapping va_list and __va_list to __gnuc_va_list.
>A better way is to dynamically fix header files. This was suggested
>in the discussion regarding the change to the header search implementation.
I didn't follow that discussion, but it's a pretty slick idea. It would
solve the problem of how to deal with installing vendor patches which tweak
header files after GCC was installed.
Do you know if anyone is working on this?
>One way might be similar to that used for web pages in browsers. If
>a header "changes", a cache of fixes could be updated. As a result,
>gcc wouldn't get out of date. The private include directory of gcc
It wouldn't totally disappear as GCC still has its own varargs, stddef
and a few other header files. But what would disappear would be the
slightly modified copies of the vendor's include files.