public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: HPPA STMP_FIXPROTO patch
@ 2002-08-29 16:40 John David Anglin
  2002-08-30  9:02 ` Jeff Law
  0 siblings, 1 reply; 3+ messages in thread
From: John David Anglin @ 2002-08-29 16:40 UTC (permalink / raw)
  To: gcc; +Cc: law, sje

> > Really the way to go is to get HP to fix the hpux header files so that neither
> > fixincludes nor fixproto are necessary.  Then it becomes a hell of a lot easier
> > 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.

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
would disappear.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: HPPA STMP_FIXPROTO patch
  2002-08-29 16:40 HPPA STMP_FIXPROTO patch John David Anglin
@ 2002-08-30  9:02 ` Jeff Law
  2002-08-30 10:16   ` John David Anglin
  0 siblings, 1 reply; 3+ messages in thread
From: Jeff Law @ 2002-08-30  9:02 UTC (permalink / raw)
  To: John David Anglin; +Cc: gcc, sje

In message < 200208292340.g7TNeCMS027636@hiauly1.hia.nrc.ca >, "John David Anglin
" writes:
 >> > Really the way to go is to get HP to fix the hpux header files so that ne
 >ither
 >> > fixincludes nor fixproto are necessary.  Then it becomes a hell of a lot 
 >easier
 >> > 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
 >would disappear.
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.

jeff

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: HPPA STMP_FIXPROTO patch
  2002-08-30  9:02 ` Jeff Law
@ 2002-08-30 10:16   ` John David Anglin
  0 siblings, 0 replies; 3+ messages in thread
From: John David Anglin @ 2002-08-30 10:16 UTC (permalink / raw)
  To: law; +Cc: gcc, sje

> Do you know if anyone is working on this?

Not that I am aware of.  It was Paul Eggert's suggestion:

< http://gcc.gnu.org/ml/gcc/2002-08/msg00106.html >.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-08-30 10:16 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-29 16:40 HPPA STMP_FIXPROTO patch John David Anglin
2002-08-30  9:02 ` Jeff Law
2002-08-30 10:16   ` John David Anglin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).