On Thu, 2002-05-16 at 16:19, Gwenole Beauchesne wrote: > Hi, > > > cc1: warning: changing search order for system directory "/usr/include" > > cc1: warning: as it has already been specified as a non-system > > directory > > Package is (badly) adding system include dir to include search path. In > some occasions, that would inhibit features to be found by configure > because the result in misinterpreted. aka. doesn't parse that warning > and acts as if it resulted in an error. > > Solution: fix the package so that it doesn't -I/usr/include, or > -I/usr/local/include explicitly.
That doesn't make sense. It quite logical to have a software product environment where you are trying to compile using some "variance" of a header that is found in a "system" header directory and need it searched first; or you need to force the system directories to be searched before some "product" directory that incorrectly includes "system" headers. To do that, you need to be able to specify the search order of any directories that have headers in them, otherwise you get the wrong version. This has been a very common practice in my 13 years of software development environment administration. I looked in the gcc 3.1 man page, and you are correct though. It specifically states that it expects to deal with the search order of "system" headers itself, unless you specify -nostdinc on the command line. Odd that the gcc team would do this (it definitely will weigh heavily in my company's evaluation of moving to gcc). But I suppose this is a gcc mailing list issue, not a cooker issue..... -- TTFN, Lonnie Borntreger
