Mail Archives: cygwin/2005/03/19/20:41:24
cgf wrote:
>On Sun, Mar 20, 2005 at 09:21:42AM +1200, Danny Smith wrote:
>>On native mingw build I get this:
>>
>>#include "..." search starts here:
>>#include <...> search starts here:
>> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../include
>> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/include
>> D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../mingw32/include
>> /mingw/lib/gcc/mingw32/3.4.3/../../../../include
>> /mingw/include
>> /mingw/lib/gcc/mingw32/3.4.3/include
>> /mingw/lib/gcc/mingw32/3.4.3/../../../../mingw32/include
>> /mingw/include
>>End of search list.
>>
>>As far as I can remember (gcc 2.95.3) the mingw include dir has preceded the
>>gcc include dir.
>
>In the above, the mingw directory is intermixed multiple times with the
>gcc include directory. Unless I'm missing something, if cygwin and
>linux are any indication, that's sort of unusual.
>
Duplicate entries do not get removed because the code that does that depends on
working inode numbers. mingw has an unusual file system
Some of the duplicates are there because they derive from the prefix as set
during build, while others (the once that start with D:/MINGW/BIN derive from
the make-relative-prefix relocations
The first include of /mingw/include
(D:/MINGW/BIN/../lib/gcc/mingw32/3.4.3/../../../../include)
is actually the LOCAL_INCLUDE_DIR, which on mingw is constructed by sed to be
relative to EXEC_PREFIX.
Danny
>cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -