This is the mail archive of the gcc@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: /usr/local/include before /usr/include?


Brian Ford <ford@vss.fsi.com> writes:
> On Fri, 25 Feb 2000, David Starner wrote:

>> Aren't /usr/local/include files system includes?

> Supplementary ones, yes.  Overriding ones, no.

I think you'll find the common expectation to be different.  Consider a
Linux system, for example, which often has quite a few libraries like
libpng installed in /usr/lib with includes in /usr/include.  If a sysadmin
compiles their own libpng and puts the headers in /usr/local/include, it's
generally expected that this will override the system include files and
that the library in /usr/local/lib will be found before the default system
one.

> Most vendor compilers would not look there.  So, she has only overriden
> it for gcc.  If that was the desired intention, then why didn't she just
> put the overriding include in gcc's fixed include directory?

Ridiculously difficult to find, for one, which results in a documentation
problem the next time someone (possibly a completely different sysadmin)
upgrades gcc.

> And again, if you want /usr/local/include first, all you have to do is
> -I /usr/local/include.  It seems silly to have to -I/usr/include to
> assure system headers get priority.

Given that the headers in /usr/local/include are under local control and
the headers in /usr/include often aren't, under what conditions would it
normally be necessary to force /usr/include to be searched first?  Surely
it would be easier to remove the incorrect headers in /usr/local/include?

-- 
Russ Allbery (rra@stanford.edu)         <URL: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]