On 2002.05.17 Lonnie Borntreger wrote:
>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.....
>

It can be because gcc just does that, It 'fixes' system headers to
correct some odd things, and stores its modified versions in, say,
/usr/lib/gcc-lib/3.1.0/include. So default includepath for gcc is
really -I/usr/lib/gcc-lib/3.1.0/include -I/usr/include.
(the full real path for 3.1 is:
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.1/include)


Then if you put by hand /usr/include again, you are forcing gcc to
get the faulty headers again. So it should not be done.



-- 
J.A. Magallon                           #  Let the source be with you...        
mailto:[EMAIL PROTECTED]
Mandrake Linux release 8.3 (Cooker) for i586
Linux werewolf 2.4.19-pre8-jam3 #1 SMP vie may 17 02:01:57 CEST 2002 i686

Reply via email to