Re: fixincl on linux systems

["Andi Kleen" <ak at suse dot de>]

On Mon, Sep 25, 2000 at 11:06:48AM -0700, Bruce Korb wrote:
> > > 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.

What I meant is that it is sometimes not easy to find all private
include directories. For example I tend to install gccs into 
/pkg/gcc-date/. Try to find it there. To make fixincl be runable for
rpm install script you would need a global fixincl that reads some global
configuration file that contains the paths of all installed gccs.
I'm not sure if that would be desirable, probably not.

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

glibc-1 (libc5) is a separate gcc configuration anyways.

AFAIK The only case that really needs fixing in glibc2+ setups was the inline
assembly in the glibc 2.0 FD_* macros for select. This is a single file
(and has been fixed for years BTW too) 

But how about the GCC builder who knows what he is doing ? For example
if I was generating a gcc rpm I would definitely not want to have random
fixed includes in the rpm [all other package systems probably have similar
problems]. For that using --disable-fixincl would make a lot of sense.

There would be probably another way that works for the casual gcc
builder who really compiles gcc from source, for these your white list 
approach makes sense, and making sure that only the minimum number
of files are fixed to keep the risk of binary incompatibilities low. 

-Andi