This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: /usr/local/include before /usr/include?
- To: gcc at gcc dot gnu dot org
- Subject: Re: /usr/local/include before /usr/include?
- From: Russ Allbery <rra at stanford dot edu>
- Date: 25 Feb 2000 23:56:05 -0800
- Organization: The Eyrie
- References: <Pine.GSO.4.21.0002251315240.24389-100000@eos>
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/>