This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fixincl on linux systems
Andi Kleen wrote:
> For Linux it would be better if it was a white-list, not a black list.
Well, OK, each platform could choose between defining a BYPASS or
a SELECT define (obviously not both :-). The general idea is there.
> > That would be solvable if fix-headers and fixincl were a single,
> > separable
> > process. You cannot just install "fixincl" and rerun it because of what
> > fix-headers does later :-(.
>
> It would break anyways with multiple gcc versions installed. I tend to
> not replace the system compiler with a gcc 2.96 test, but install it into
> some private directory and call it explicitely.
Each version of GCC has its own private fixed-include directory:
$ ls -1 /usr/local/lib/gcc-lib
i386-pc-sco3.2v5.0.5
i686-pc-sco3.2v5.0.5
Were there to be an installable ``apply-all-fixes'' program,
the fixed headers would not interfere with each other.
> > I hate command line switches that are always used in one context
> > and never used in another. Better to have the context be queried about
> > or provide the information, as I have suggested above.
>
> I'm not sure I follow. There are certainly lots of contexts where a user
> can say that he doesn't care about all of /usr/include.
Presumably, it would be where the person responsible for the port
was certain that a fix was not necessary. It used to be the case
that it was not necessary for Linux, but lo a problem arose for
glibc-1. So, forevermore, Linux must be processed. Unless you
distinguish based on libc version. Requiring the "hapless" GCC
builder to learn and understand the significance of "--disable-fixinc"
would not be good.
> Context querying is usually fragile, and it would make
> sense to allow the user to override it when he knows what he is doing
> (similar to e.g. he can say --disable-nls)
And such options as that are only usable by the cognoscenti.
I would venture to guess that most people who download and build
GCC do not want to know about obtuse options, and also do not want
to run into the RPM upgrade problem you describe.